Comments 22
Что-то терзают меня сомнения насчет 7-wide superscalar. В свое время (конец 80-х) были проведены исследования, по результатам которых оказалось, что нет никакого смысла делать суперскалярные машины, способные выполнять больше 3-4 команд одновременно. Причем это число зависит исключительно от кода, который выполняется на процессоре, а точнее, от instruction-level parallelism в этом коде (т.е., грубо говоря, от количества идущих друг за другом ассемблерных команд, независимых друг от друга, которые можно выполнить параллельно).
А 192 ядра CUDA — это не superscalar. Это 7 SPU, которые независимо работают.
Напомню вам одну известную цитату, тоже из 80-х: «640KB хватит с избытком.»
Я к тому, что возможно все-таки не стоит опиратся на исследования «конца 80-х» в настолько стремительно меняющейся отрасли.
Я к тому, что возможно все-таки не стоит опиратся на исследования «конца 80-х» в настолько стремительно меняющейся отрасли.
В IBM Power8 с декодера может приходить до 10 инструкций и отправляться на исполнение до 8 инструкций. Ограничение 3-4 инструкции связано не со способностью испольнения, а с ограничениями на размер чипа. Линейное увеличение количества одновременно выполняемых команд приводит к квадратичному увеличению размеров внутренних структур, различных буферов и т.п. Чтобы запускать больше инструкций нужно иметь возможность изучить/видеть больше инструкций, так называемое окно инструкций. Увеличили окно, нужно увеличивать буфера, где хранится, то что просмотрели. Все это в свою очередь приводит к увеличению потребления power.
Это точно восемь команд из одного потока, или по одной команде из восьми потоков?
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.
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.
В оригинале вон пишут что они приделали что-то типа JIT/hot-spot-компиляции: оно софтверно перекомпилирует/переоптимизирует код в специальный буфер. И в этот момент, видимо, смотрит сразу как ему что параллелить.
Вообще забавно будет на том же андроиде — JVM JIT-ит в ассемблер ARM, а потом процессор еще из ассемблера ARM делает что-то своё :)
Вообще забавно будет на том же андроиде — JVM JIT-ит в ассемблер ARM, а потом процессор еще из ассемблера ARM делает что-то своё :)
сложно сказать наверняка, но походу процессор делает из ассемблера ARM ассемблер ARM, т.е. там нет собственного внутреннего представления. Оптимизация заключается в том, что они разворачивают циклы, переставляют команды местами, переименовывают регистры и т.д., т.е. заменяют исходный код на такой же, но жестоко оптимизированный по быстродействию в ущерб размеру. В принципе, подобную оптимизацию делают и обычные суперскалярные процессоры (разве что циклы они не разворачивают) — но Нвидия надеется получить профит за счет гораздо большего «окна» (обещают в пять раз большее окно, около тысячи команд).
Непонятно, да. Там пишут "… which optimizes frequently used software routines at runtime into dense, highly tuned microcode-equivalent routines ...". Т.е. в какой-то микрокод они компилируют. Вероятно — во что-то типа VLIW. Но тогда не ясно почему они пишут про superscalar — этот термин вроде как противоположен VLIW, т.к. подразумевает распараллеливание на лету.
При наличии окна переупорядочивания в 100+ инструкций, загрузить исполнительные блоки куда проще.
Даже Cortex-A15 может выполнять 8 инструкций за такт (декодировать только 3)
www.extremetech.com/computing/139393-arm-cortex-a15-explained-intels-atom-is-down-but-not-out
Даже Cortex-A15 может выполнять 8 инструкций за такт (декодировать только 3)
www.extremetech.com/computing/139393-arm-cortex-a15-explained-intels-atom-is-down-but-not-out
Тем не менее, в той статье, которую мы тут обсуждаем, A15 назван «3-way superscalar», что, похоже, намекает на то, что считается именно количество декодируемых за такт команд.
Декодер отвязан от остальной части чипа. По факту в какие-то моменты может выполняться меньше трёх, а в какие-то больше трёх инструкций на такт, сохраняя средний темп в три инструкции на такт.
Сравнивать «ширину» VLIW и RISC некорректно. У VLIW количество декодируемых команд равно количеству портов запуска.
Декодирование и переупорядочивание инструкций в данном случае возложено на firmware, вместо аппаратных блоков как в A15.
Из кеша L1I в планировщик идут уже подготовленные микрооперации, а не ARM инструкции (в случае наличия этого самого оптимизированного кода)
Сравнивать «ширину» VLIW и RISC некорректно. У VLIW количество декодируемых команд равно количеству портов запуска.
Декодирование и переупорядочивание инструкций в данном случае возложено на firmware, вместо аппаратных блоков как в A15.
Из кеша L1I в планировщик идут уже подготовленные микрооперации, а не ARM инструкции (в случае наличия этого самого оптимизированного кода)
А интересно, насколько «тяжелый» медиаконтент сможет потянуть?
Вот что-то сомневаюсь насчет 4К 120 Гц.
Вот что-то сомневаюсь насчет 4К 120 Гц.
Из комментариев к оригинальной статье:
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.
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.
Больше подробностей в комментарии 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 может выполняться в моменты простоя процессора из-за промахов в кэш.
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 может выполняться в моменты простоя процессора из-за промахов в кэш.
beeruser
Хм, я правильно понимаю, что DCO наибольший профит даст для ПО, вращающегося в managed-рантаймах в Android и Windows RT? В теории рантаймы-же можно подтюнить для DCO?
В данном случае преимущество DCO в том, что многие оптимизации горячего участка кода выполняются лишь один раз и используются в дальнейшем повторно для каждой итерации горячего кода
Хм, я правильно понимаю, что DCO наибольший профит даст для ПО, вращающегося в managed-рантаймах в Android и Windows RT? В теории рантаймы-же можно подтюнить для DCO?
Sign up to leave a comment.
NVIDIA представила 64-разрядный Tegra K1 процессор с двумя ядрами Denver