NVIDIA представила 64-разрядный Tegra K1 процессор с двумя ядрами Denver



    Компания NVIDIA представила новый процессор Tegra K1 еще в январе, на Хабре была соответствующая публикация. Тогда было известно о 32-разрядном четырех-ядерном Cortex-A15 процессоре. Говорилось и о том, что будет выпущен 64-разрядный процессор с двумя ядрами Denver собственной разработки от NVIDIA.

    Вчера в блоге компании появилась более подробная информация о второй разновидности чипа, можно сказать, состоялась официальная презентация этого процессора.

    К сожалению, точные сроки появления этого чипа не называются, но характеристики процессора все же представлены. Так вот, 64-разрядная версия Tegra K-1 «заточена» под работу с новой ОС Android L (разработчики утверждают, что производительность двух-ядерного процессора Tegra K-1 выше, чем у «мобильных» четырех и восьмиядерных процессоров). При этом обе версии процессора имеют совместимые контактные площадки, поэтому материнские платы не требуют переделки.



    Tegra K-1 с Denver предназначаются, в первую очередь, для работы с «тяжелыми» приложениями, включая игрушки, а также с не менее «тяжелым» медиаконтентом.

    Что касается двух ядер Denver, то к ним прибавляется и 192 ядра CUDA графической подсистемы Kepler, что позволяет за один такт обрабатывать семь инструкций, а также сохранять используемые чаще всего участки программного кода в 128 МБ буфере. Этот процесс назван Dynamic Code Optimization. Каждое из двух ядер включает 128 КБ 4-way L1 instruction cache, 64 КБ 4-way L1 data cache, и 2 МБ 16-way L2 cache.



    По словам разработчиков, 64-разрядные процессоры весьма энергоэффективны, чипы работают, используя динамическое изменение как частоты, так и напряжения. Разработчики также утверждают, что такие процессоры сравнимы по производительности с Apple A7 или Celeron 2955U/Haswell.

    Устройства на базе 64-bit Tegra K1 будут выпущены уже в этом году, правда, дата выхода таких устройств и их описание не предоставлено.

    Via nvidia
    Support the author
    Share post

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 22

      +2
      Что-то терзают меня сомнения насчет 7-wide superscalar. В свое время (конец 80-х) были проведены исследования, по результатам которых оказалось, что нет никакого смысла делать суперскалярные машины, способные выполнять больше 3-4 команд одновременно. Причем это число зависит исключительно от кода, который выполняется на процессоре, а точнее, от instruction-level parallelism в этом коде (т.е., грубо говоря, от количества идущих друг за другом ассемблерных команд, независимых друг от друга, которые можно выполнить параллельно).

        0
        А 192 ядра CUDA — это не superscalar. Это 7 SPU, которые независимо работают.
          +7
          А причем здесь CUDA?

          Кстати, ответ на мой вопрос нашелся в оригинале статьи. И должен сказать, что автор перевода просто выкинул самое интересное. Читайте оригинал, и желательно в это время сидеть на чем нибудь твердом, чтоб не упасть…
            +1
            Да, действительно, оригинал лучше.

            Я интерпретировал то что в переводе написано «192 ядра CUDA, что позволяет»…
          –4
          Напомню вам одну известную цитату, тоже из 80-х: «640KB хватит с избытком.»
          Я к тому, что возможно все-таки не стоит опиратся на исследования «конца 80-х» в настолько стремительно меняющейся отрасли.
            –2
            Сам не проверял, но многие утверждают, что такой фразы он не говорил. Дальше вариации. Либо он это говорил, но вырвано из контекста, либо сказал вообще не он.
              +3
              либо сказал вообще не он
              Спасибо кэп, а не подскажете, где это я сказал, что это он?
              В отношении моего коментария, имхо глубоко без разницы кто и в каком контексте это сказал (в 80-х речь вероятно шла все-равно про ОЗУ).
                +1
                Если эту цитату знают все, значит кто-то это всё-таки сказал.
              0
              В IBM Power8 с декодера может приходить до 10 инструкций и отправляться на исполнение до 8 инструкций. Ограничение 3-4 инструкции связано не со способностью испольнения, а с ограничениями на размер чипа. Линейное увеличение количества одновременно выполняемых команд приводит к квадратичному увеличению размеров внутренних структур, различных буферов и т.п. Чтобы запускать больше инструкций нужно иметь возможность изучить/видеть больше инструкций, так называемое окно инструкций. Увеличили окно, нужно увеличивать буфера, где хранится, то что просмотрели. Все это в свою очередь приводит к увеличению потребления power.
                0
                Это точно восемь команд из одного потока, или по одной команде из восьми потоков?
                  0
                  POWER8:

                  The POWER8 core has 64 KB L1 data and 32 KB L1 instruction caches. Each core can issue 10 instructions and dispatch 8 each cycle to 16 Execution Units (EU); 2× Fixed-Point Units (FXU), 2× Load-Store Units (LSU), 2× Instruction Fetch Units (IFU), 4× Floating Point Units (FPU), 2× VMX units, 1× Cryptographic Unit, 1× Decimal Floating Unit (DFU), 1× Condition Register Unit (CRU), and 1× Branch Register Unit (BRU).

                  Так как он поддерживает SMT8, то скорее всего либо 8 из одного, либо по одной из 8-ми. Он имеет 12 ядер и его размер 650 мм^2. Для сравнения Haswell Core i7 Extreme имеет 8 ядер (SMT2) и размер 177 мм^2.
                  0
                  В оригинале вон пишут что они приделали что-то типа JIT/hot-spot-компиляции: оно софтверно перекомпилирует/переоптимизирует код в специальный буфер. И в этот момент, видимо, смотрит сразу как ему что параллелить.

                  Вообще забавно будет на том же андроиде — JVM JIT-ит в ассемблер ARM, а потом процессор еще из ассемблера ARM делает что-то своё :)
                    0
                    сложно сказать наверняка, но походу процессор делает из ассемблера ARM ассемблер ARM, т.е. там нет собственного внутреннего представления. Оптимизация заключается в том, что они разворачивают циклы, переставляют команды местами, переименовывают регистры и т.д., т.е. заменяют исходный код на такой же, но жестоко оптимизированный по быстродействию в ущерб размеру. В принципе, подобную оптимизацию делают и обычные суперскалярные процессоры (разве что циклы они не разворачивают) — но Нвидия надеется получить профит за счет гораздо большего «окна» (обещают в пять раз большее окно, около тысячи команд).
                      0
                      Непонятно, да. Там пишут "… which optimizes frequently used software routines at runtime into dense, highly tuned microcode-equivalent routines ...". Т.е. в какой-то микрокод они компилируют. Вероятно — во что-то типа VLIW. Но тогда не ясно почему они пишут про superscalar — этот термин вроде как противоположен VLIW, т.к. подразумевает распараллеливание на лету.
                  0
                  При наличии окна переупорядочивания в 100+ инструкций, загрузить исполнительные блоки куда проще.
                  Даже Cortex-A15 может выполнять 8 инструкций за такт (декодировать только 3)

                  www.extremetech.com/computing/139393-arm-cortex-a15-explained-intels-atom-is-down-but-not-out
                    0
                    Тем не менее, в той статье, которую мы тут обсуждаем, A15 назван «3-way superscalar», что, похоже, намекает на то, что считается именно количество декодируемых за такт команд.
                      +1
                      Декодер отвязан от остальной части чипа. По факту в какие-то моменты может выполняться меньше трёх, а в какие-то больше трёх инструкций на такт, сохраняя средний темп в три инструкции на такт.

                      Сравнивать «ширину» VLIW и RISC некорректно. У VLIW количество декодируемых команд равно количеству портов запуска.
                      Декодирование и переупорядочивание инструкций в данном случае возложено на firmware, вместо аппаратных блоков как в A15.
                      Из кеша L1I в планировщик идут уже подготовленные микрооперации, а не ARM инструкции (в случае наличия этого самого оптимизированного кода)
                  0
                  А интересно, насколько «тяжелый» медиаконтент сможет потянуть?
                  Вот что-то сомневаюсь насчет 4К 120 Гц.
                    +1
                    Из комментариев к оригинальной статье:

                    In other words, it is an in-order VLIW core with a dynamic recompiler ARM emulator in firmware. Like the old «x86» chips from Transmeta. Interesting design choice, we'll see how well it works in practice.
                      +1
                      Мне кажется что даже слабовидящий увидит на диаграмме ARM HW Decoder. Т.о. выполнять нативный ARM код без рекомпиляции он умеет. В отличии от Трансметы.
                      А рекомпиляцию следует совершать в фоне, чтобы со временем проги выполнялись быстрее =)
                      +5
                      Больше подробностей в комментарии XSol на ixbt:
                      ixbt.com/news/hard/comments.shtml?18/18/70#cmt_310603

                      DCO не подменяет аппаратные декодеры, не вводите людей в заблуждение. У Трансметы декодирование внешних Х86 команд производилось программными методами, по сути была программная интерпретация с соответствующим уровнем базовой производительности без дополнительной оптимизации программного микрокода. В данном же случае декодирование производится специализированными аппаратными блоками — ARM HW Decoder на блок схеме, как у всех остальных современных процессоров.
                      В результате уровень базовой производительности процессора в случае отсутствия оптимизаций DCO должен быть на уровне конкурентных решений с равным кол-вом аппаратных декодеров и схожими характеристиками, судя по описанию в NVIDIA-Project-Denver-White-Paper, в данном случае минимальной(базовой) является производительность на такт аналогичная Крайту (Krait 400 архитектура) в S805 — половина производительности с DCO.
                      Когда использовать динамическую оптимизацию кода(DCO) процессор решает по значениям внутренних аппаратных счетчиков, в которых хранится профилировочная информация. Если обнаруживается «горячий» участок кода — циклы, ф-ции и т.д.(см. правило 80/20, большую часть времени выполнения занимает меньшая часть кода в которой данные проходят циклическую обработку), то декодированный (аппаратными ARM декодерами) микрокод горячего участка подвергается динамической оптимизации соответствующего firmware(DCO) — перестановке операций, удалению мертвых операций, переименованию регистров и прочим оптимизациям, которые возможно эффективно выполнять на основании информации полученной по ходу выполнения программы(профилировочная информация во внутренних регистрах процессора). Программно DCO firmware делает ряд преобразований, которые в более традиционных реализациях выполняются аппаратными блоками, из преимуществ — возможность анализа большего окна инструкций, порядка 1000 инструкций против 192 в аппаратных реализациях самых производительных процессоров, из потенциальных недостатков — DCO применяется только к горячим участкам кода, аппаратная реализация работает всегда(нет минимального базового уровня производительности), короткоживущие одноразовые участки кода не оптимизированные DCO будут работать на базовом уровне производительности ЦПУ(что не столь важно, т.к. такие участки пробегают очень быстро на любых процессорах). Некоторые блоки, вроде блока предсказаний ветвлений и блоков предварительной выборки при этом по прежнему аппаратные. После, DCO добавляет указатель на оптимизированный микрокод «горячего участка» в таблицу и сохраняет микрокод во внешний участок dram объемом 128 мб., можете рассматривать данный участок как аналог трейс кэша P4, только во внешней памяти(кэшируемой), DCO может связывать такие оптимизации в цепочки, соответственно когда процессор войдет в очередную итерацию горячего кода у него уже будет оптимизированный микрокод в кэше инструкций, при нахождении DCO оптимизации, повторное декодирование внешних ARM инструкций горячего кода пропускается. В данном случае преимущество DCO в том, что многие оптимизации горячего участка кода выполняются лишь один раз и используются в дальнейшем повторно для каждой итерации горячего кода, тогда как традиционные процессоры проводят одни и те же оптимизации заново для каждой итерации, кроме того, DCO может выполняться в моменты простоя процессора из-за промахов в кэш.
                        0
                        beeruser
                        В данном случае преимущество DCO в том, что многие оптимизации горячего участка кода выполняются лишь один раз и используются в дальнейшем повторно для каждой итерации горячего кода

                        Хм, я правильно понимаю, что DCO наибольший профит даст для ПО, вращающегося в managed-рантаймах в Android и Windows RT? В теории рантаймы-же можно подтюнить для DCO?

                      Only users with full accounts can post comments. Log in, please.