__>Что думаете по этому поводу?
Концепция разных по производительности ядер требует от самого софта указывать какой тип ядра на данный момент нужен коду.
И вот фигня — это нигде на уровне языка не реализовано — поэтому и не работает как положено.
Введенный в ОС "интеллектуальный" помогатор наделен интеллектом улитки и не наделен телепатией,
поэтому потоки работающие в стиле "то пусто — то густо" всегда будут провисать и бесить пользователя неисправимыми тормозами.
На текущий момент "экономичные" ядра — маркетинговый мусор вызывающий случайные тормоза и фризы и не повышающий производительность.
Здравствуйте, alpha21264, Вы писали: A>Я участвовал в проектировании отечественного процессора, и знаю в подробностях, как это всё работает.
Какого? Скалярного или суперскалярного? A>Так в чём разница между быстрыми и экономичными ядрами? Ведь всё это всё равно надо сделать.
Ладно, раз пошла такая пьянка, то пойдём в документацию, а именно в Intel® 64 and IA-32 Architectures Optimization Reference Manual: Volume1, от 2024. Смотреть будем на 12 поколение: 13-е в плане архитектуры не имеет принципиальных отличий. Чтобы увидеть, что делать можно по-разному сразу же лезем в описание гибридной архитектуны. На странице 2-7 мы увидим довольно примечательный текст:
Additionally, different software threads see different performance ratios between the P-cores and
E-cores. For example, the performance ratio between the P-cores and E-cores for highly vectorized floating-point
code is higher than that for scalar integer code. So, when the operating system must make an optimal scheduling
decision, it must be aware of the characteristics of the software threads that are candidates for scheduling. Suppose
there are insufficient P-cores and a mix of software threads with different characteristics. In that case, the operating
system should schedule those threads that benefit most from the P-cores onto those cores and schedule the others
on the E-cores.
Т.е. для элементарного сложения двух целых чисел нет большой разницы, на чём его исполнять, но для кода активно использующего SIMD разница значительная.
Я уже писал, что делать можно по-разному — очень многое, на целую статью тянет, слишком круто для ответа на форуме. И оптимизировать можно разные операции. Например, можно оптимизировать операции с частями регистров. Это явно можно увидеть в сносках к таблице 2-3, указанного мануала:
. The Golden Cove microarchitecture implemented performance improvements requiring constraint of the microops which use *H partial registers (i.e. AH, BH, CH, DH). See Section 3.5.2.3 for more details.
Пойдём дальше и посмотрим, что именно произошло:
From Skylake to Ice Lake microarchitectures, operations that access *H registers (i.e., AH, BH, CH, DH) are executed
exclusively on ports 1 and 5.
The *H micro-ops are executed with one cycle latency; however, one cycle of *additional* delay is required for
ensuing UOPs because they depend on the results of the *H operation. This additional delay is required due to
potential data swapping. A swap might happen, for example, with the instruction "Add AH, BL", or "ADD AL, BH." The
pipeline functionality is illustrated in Figure 2-4. Beginning with the Golden Cove Microarchitecture, the *H operations are limited to Port 1 (port1) with three cycles
of latency. This penalty on *H operations helped performance improvement and timing requirements of the Golden
Cove microarchitecture.
А ещё можно принципиально по-разному организовать выполнение AVX инструкций на энергоэффективных и неэнергоэффектинвых ядрах:
4.1.9 LEGACY INTEL® AVX1/INTEL® AVX2 INSTRUCTION SUPPORT
The Crestmont microarchitecture continues to support Intel® AVX and Intel® AVX2 instructions.
Most 256-bit Intel AVX and Intel AVX2 instructions are decoded as a single instruction and stored as a single μop in the
front-end pipeline. To execute 256-bit instructions on native 128-bit vector execution and load data paths, most
256-bit μops are further subdivided into two independent 128-bit μops at allocation before insertion into the MEC
and FPC reservation stations. These two independent μops are usually assigned to different execution ports, so both
may execute in parallel. In general, 256-bit μops consume twice the allocation, execution, and retirement resources
compared to 128-bit μops.
Для сравнения, что при этом происходит на производительных ядрах (страница 2-26):
Since port 0 and port 1 are 256-bits wide, Intel AVX-512 operations that will be dispatched to port 0 will execute on
port 0 and port 1; however, other operations such as LEA can still execute on port 1 in parallel. See the red block in
Figure 2-9 for the fusion of ports 0 and 1
Можно делать энергоэффективно, как в Атомах, или максимально быстро как в производительных ядрах. Тащемта микроархитектура Gracemont — наследница микроархитектуры атомов.
Я в предыдущем сообщении уже писал где отличия могут быть. Чтобы полностью описать разницу между Golden Cove и Gracemont, нужно сюда почти полностью скопировать документацию. Можно более кратко — посмотреть на блок-схему этих ядер. Предлагаю последнее:
производительные ядра
энергоэффективные ядра
Думаю заметно и без детального описания, что Golden Cove значительно проще. Также должно быть заметно, что ROB для первых 256, а для вторых — 512. Уже это довольно серьёзно влияет на энергопотребление. Также должно быть хорошо видно, что у первого диспатчер выдаёт 6 микроопераций за такт, а у второго 5. A>Наш процессор в экономичном режиме не занимался переупорядочиванием инструкций (и всякой другой фигнёй), A>а просто замирал до тех пор, пока данные не приходили из памяти.
А в неэкономичном? Он вообще этим занимался? Это был суперскалярный или скалярный процессор? Можно взглянуть на документацию?
Переупорядочивание инструкций используется для организации параллелизма на уровне инструкций. Т.е. у тебя могут быть заняты все юниты, которые могут прямо сейчас исполнить следующую микрооперацию. Например это может быть какая-то операция над числами с плавающей точкой. Однако могут быть свободны юниты, выполняющие целочисленные микроперации. В этом случае "THE OUT-OF-ORDER EXECUTION ENGINE" используя буфер(а) переупорядочивания (ROBs) может начать выполнение целочисленной микрооперации, хотя в исходном коде "целочисленный код" идёт после кода перемалывающего числа с плавающей точкой. Или ещё пример, т.к. в атомах (Crestmont, Gracemont, TREMONT) существуют отдельные сдвиговые исполнительные устройства, то вполне возможно, что следующий код выполнится в обратном порядке:
shl eax, cl
add edi, 64
Тебе по большому счёту всё равно в каком порядке он исполняется. A>При этом не тратил ни одного лишнего такта на лишнюю работу.
Это что означает, как понимать? Причём тут лишняя работа? Как определить что она лишняя?
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Teolog, Вы писали:
T>Концепция разных по производительности ядер требует от самого софта указывать какой тип ядра на данный момент нужен коду. T>И вот фигня — это нигде на уровне языка не реализовано — поэтому и не работает как положено.
А с чего вдруг на уровне языка!? На кой ляд вообще в язык тянуть то, что не относится к написанию алгоритмов или описанию структур данных?
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
Ф>Можно делать энергоэффективно, как в Атомах, или максимально быстро как в производительных ядрах. Тащемта микроархитектура Gracemont — наследница микроархитектуры атомов. Ф>Я в предыдущем сообщении уже писал где отличия могут быть. Чтобы полностью описать разницу между Golden Cove и Gracemont, нужно сюда почти полностью скопировать документацию. Можно более кратко — посмотреть на блок-схему этих ядер.
Для меня процессор "черный ящик" и я по ламерски спрошу.
1) там же внутри микрокод. когда интел\амд выпускает "неудачный" процессор, они рассылают патчи микрокода для исправления ошибок и таки исправляют. да?
значит процессор можно произвольно (относительно) переконфигурировать как хочешь.
(кстати — интересный вектор атаки, когда компы вероятного противника начинают считать 2+2 = 4.003)
2) борьба за энергоэффективность ведется давно, и давно уже есть процы которые могут понижать или повышать частоту ядер внутри себя / шины снаружи.
Вопрос первый: что мешает сейчас делать все ядра одинаковыми и переконфигурировать их (часть из них) "на лету" под текущие задачи?
Если уж не хочется "на лету" переконфигурировать ядра Второй вопрос: раньше было true SMP, с несколькими физическими cpu. что этому мешает сейчас? запаять на материнку _И_ atom n100 в роли энергоэффективного, _И_ Core i9 ?
задачи они будут решать разные, кэши level1 level2 и даже level3 не пересекаются.
Здравствуйте, Stanislaw K, Вы писали:
SK>Для меня процессор "черный ящик" и я по ламерски спрошу.
Я не знаю. Мои отрывочные знания происходят из интеловских мануалов и тех статей, на которые натыкался в интернетах. Я не проектирую кремниевую электронику — я ей пользуюсь.
На первый вопрос у меня есть предположение: мало снижать частоту и напряжение, жор зависит от самого устройства. Тот же буфер перестановок (его размер) и кэш, а особенно глубоко ассоциативный должны быть уже сами по себе достаточно жористыми. Тоже самое относится к файлу регистров: чем больше, тем более жористый. Повторюсь: это предположение. Я не могу точно сказать, что энергетически выгоднее для выполнения какого-нибудь алгоритма над одинаковым набором данных: большой кэш, или маленький и т.д. Просто потому, что маленький кэш будет давать больше кэш-промахов — может оказаться так, что из-за них будет в конечном счёте больше переключений транзисторов из закрытого состояния в открытое и наоборот. Именно последнее — источник потребления энергии: каждый транзистор имеет паразитную ёмкость, каждый проводник — паразитная ёмкость, какждый проводник — паразитная индуктивность и т.д.
Т.о. если в статьях пишут, что увеличение ROB увеличивает жор, то я этому вынужден верить. У меня нет возможности это проверить никак.
Далее, я сильно сомневаюсь, что можно вот так легко и просто выключить из работы больше половины ядра. Подозреваю, что это слишком сложная задача, а может и нерешаемая.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Stanislaw K, Вы писали:
SK>значит процессор можно произвольно (относительно) переконфигурировать как хочешь.
В очень узких пределах.
Переконфигурировать как хочешь — это может делать FPGA, но в процессоре ничего подобного нет.
SK>(кстати — интересный вектор атаки, когда компы вероятного противника начинают считать 2+2 = 4.003)
Суммирование делает блок, полностью реализованный на уровне железа. Именить его логику нельзя.
Здравствуйте, Codealot, Вы писали:
SK>>значит процессор можно произвольно (относительно) переконфигурировать как хочешь.
C>В очень узких пределах. C>Переконфигурировать как хочешь — это может делать FPGA, но в процессоре ничего подобного нет.
Микрокод определенно имеет достаточно свободы.
SK>>(кстати — интересный вектор атаки, когда компы вероятного противника начинают считать 2+2 = 4.003)
C>Суммирование делает блок, полностью реализованный на уровне железа.
Не обязательно портить буквально именно суммирование вот так в лоб. можно иногда "корректировать" что-то другое.
C>Именить его логику нельзя.
Здравствуйте, Stanislaw K, Вы писали:
SK>Для меня процессор "черный ящик" и я по ламерски спрошу.
SK>1) там же внутри микрокод. когда интел\амд выпускает "неудачный" процессор, они рассылают патчи микрокода для исправления ошибок и таки исправляют. да? SK>значит процессор можно произвольно (относительно) переконфигурировать как хочешь.
Не так "как хочешь", сильно меньше.
Значительная часть "микрокода" это конфигурационные параметры, влияние которых ограничено на какие-то конкретные блоки или возможности.
Например, Intel так и не сумел (в отличие от ARM) сделать работающие transactional extensions (TSX), и они во всех текущих процессорах выключены, после того, как первые версии выходили с включёнными. Значит, там где-то просто лежит битик "disable_tsx", который был 0 в первых версиях микрокода, и 1 в последующих, когда убеждались, что снова не смогли.
(Кстати, почему у них не получилось, отдельный вопрос. Если где-то есть описание, скиньте ссылку.)
Или вот с твоим примером:
SK>(кстати — интересный вектор атаки, когда компы вероятного противника начинают считать 2+2 = 4.003)
перечитай про FDIV bug. Как раз после него Intel впервые ввела "микрокод", и там начали для всех блоков, которые можно подменять (как в случае блока деления для FPU), и всех микропрограмм, где они есть, вводить настройки типа "брать старую или новую версию". Новая становится безальтернативной после сбора опыта за несколько лет работы.
Но для сложения, думаю, альтернативы нет, оно уже много лет как вылизано в деталях. Деление тоже, там сейчас копать (пока) нечего. А вот варианты какого-нибудь branch prediction могут быть ой разнообразными.
Туда же, например, параметры управления кэшем памяти. Чистый LRU давно уже не используется, минимум практического это что-то в духе 2Q или S3-FIFO, и то это только самая база.
И, конечно, там ещё куча параметров тонкого тюнинга на все части процессора.
"Микрокод" в явном виде есть, но в виде патчей. Внутри x86 процессоров (всё ещё про Intel; про AMD я не слышал деталей) в каждом ядре реально ещё один вложенный x86 (однако), предельно урезанный до варианта — 32 бита, никакого out-of-order, никаких векторов и т.п. — зато быстрый. И вот он исполняет свою программу во всех случаях, когда требуется сложное исполнение. Это инициализация, переключение режимов, переключение задач, обработка исключений, вход в виртуальную машину и выход, и сложные случаи обработки обычных команд. И вот на его программу (сидящую где-то в особой быстрой памяти внутри процессора) могут приходить патчи.
Кроме того, делается что-то вроде "карты" заметной части команд (но таки не всех) с возможностью переключить их обработку на микрокод (вот тогда туда уже идут большие программы), ценой сильного замедления, конечно. Это уже спец-аварийные случаи.
Для софтовой аналогии это можно сравнить с тем, как некая программа управляется скриптами. 99% кода просто скомпилировано, но на верхней логике есть эти скрипты. И снова часть из них жёстко зафиксирована, а в части явно помечено, что тут можно отдельные блоки менять. Ещё можно сравнить с классическими GUI фреймворками, когда ты можешь переопределить пару десятков методов в потомках класса и доработать их как нужно.
У AMD, я уверен, то же самое, но внутренний процессор наверняка какой-то из RISC.
Одна из важных задач инженеров — рассчитать, что вообще надо вкладывать в микрокод для каждой новой фичи, а что не надо, чтобы на гибкости не терять производительность.
Сделать диверсию подсовыванием другого микрокода... для начала его надо адресно доставить только в конкретные процессоры. Уже сложно. Сам факт апгрейда подозрителен каждый раз. Дальше, как-то надо определить на уровне вот этого кода встроенного управляющего процессора, что здесь и сейчас надо активироваться. Хм, ну предположим. Дальше нужно найти, как именно делать диверсию. Если нет изначальной закладки на это, а у процессора нет явных дефектов, это сильно нетривиально. Я не считаю вероятность нулевой. Но она крайне низка. Через системный софт должно быть на порядки легче.
SK>2) борьба за энергоэффективность ведется давно, и давно уже есть процы которые могут понижать или повышать частоту ядер внутри себя / шины снаружи.
SK>Вопрос первый: что мешает сейчас делать все ядра одинаковыми и переконфигурировать их (часть из них) "на лету" под текущие задачи?
Много внутренних алгоритмов сделаны в реализациях, затраты на которые растут нелинейно с ростом количественной характеристики.
Например, переименование регистров для out-of-order. У тебя 16 "архитектурных" целочисленных регистров от R0 (обычно известный как RAX) до R15. На каждый надо держать данные, занят он или свободен, какая команда его последняя использует. При распределении надо контролировать, какие свободны, как мапятся архитектурные на них. Даже номер регистра в микрокомандах... Сколько будет физических — 100? 200? 300? 1000? У Skylake и ближайших потомков (не видел данных новее) конвейер до 97 команд ISA. На каждую, считаем, 2 регистра минимум. Значит, начинаем от 200? Или 400? Сколько бит на каждый — от 7 до 10? И сколько регистров в микрокоманде? Они расширяются при увеличении этого. Значит, не просто больше микрокоманд в конвейере, а они ещё и шире. Уже не N, а N log N минимум. Дальше, между ними шины обмена данными. Сколько должно быть шин, чтобы поддержать одновременно все обмены за такт? Пусть максимум скорости это 5 команд на такт, тогда 10 или 15 шин? И каждый регистр должен иметь порт обмена с каждой шиной... ой, а это уже квадратичная зависимость! Привет, O(N^2).
Или кэши памяти. При N-ассоциативности каждый запрос обрабатывается одновременно N линейками хранилища. Сравнить адрес и характеристики. 256KB 4-way кэш будет тратить на эти проверки в два раза больше энергии, чем 256KB 2-way кэш. Зато в нём заметно меньше конфликтов. L1 кэш вообще обычно полноассоциативный (например, 16KB при 64 байтах на строку это 256), на каждый запрос срабатывают проверки на всех строках. А если сделать сильно маленький кэш, промахи пойдут в L2 и так далее. Слишком экономный кэш начнёт тормозить процессор, сильно эффективный, наоборот, будет (относительно) недогружен, но при этом жрать энергии на каждую операцию.
Я не видел ещё внутреннего анализа точных характеристик новых архитектур. Но наверняка у них урезано всё, что я хоть вскользь назвал. Длина конвейера, количество физических регистров, количество АЛУ, ширина векторных блоков, размеры кэшей и т.п. В результате они на той же частоте будут тратить меньше энергии... но и медленнее разгоняться на сложные операции.
Сравни это, условно говоря, с вариантом — газель или камаз (если российскими примерами). Или понятием "платформа" для легковушки. Ставить при пятилитровом двигателе тормоза от запорожца — они не вытянут для такой машины положенное ограничение тормозного пути. Ставить на запорожец тормоза от 500го мерса — они просто будут бездействовать, зато цену машины подымут втрое. В реале у процессоров характеристики не столь различны, но всё равно есть что тюнить.
А ещё есть физические ограничения следующего рода: как ты думаешь, почему частоту ядра нельзя снижать неограниченно? Вот например смотришь — она меняется от 500МГц до 3ГГц... но ты не можешь сделать, например, 1 МГц или даже 50МГц. Почему?
А потому, что там есть место для противного компромисса: промежуточные регистры на шинах и вокруг. Их можно делать на полноценных триггерах, а можно на конденсаторах (включая таковые в виде затворов транзисторов, как в DRAM). Это я упростил (там не просто "конденсаторы", но для букваря пойдёт. я сам уже очень смутно помню.) Первые держат сколько угодно и тратят пиковатты в состоянии покоя, но процедура заливки значения и его устаканивания дольше, ещё и требуют явной синхронизации. Вторые быстро разряжаются, но запись значения в них быстрее. Минимальная частота — это такая, чтобы они не разряжались между тактами. Зато и затраты энергии на вариант с конденсаторами заметно больше. Вот и получается, что где-то при подъёме производительности есть не просто резкий подскок по затратам энергии — но и вообще используя блок, сделанный в таком стиле, ты просто не сможешь снизить затраты энергии ниже некоторого порога, который может быть выше среднего потребления "экономного" ядра.
SK>Если уж не хочется "на лету" переконфигурировать ядра SK>Второй вопрос: раньше было true SMP, с несколькими физическими cpu. что этому мешает сейчас? запаять на материнку _И_ atom n100 в роли энергоэффективного, _И_ Core i9 ? SK>задачи они будут решать разные, кэши level1 level2 и даже level3 не пересекаются.
То же самое, почему в устройствах уровня ниже "большой сервер" вообще перестали делать "true SMP".
С ~2008 года у Intel, и чуть раньше у AMD, северный мост — который сидит между процессором, с одной стороны, и памятью плюс PCI, с другой — въехал внутрь процессора. Теперь между физическими процессорами только межмостовой интерфейс, а организация памяти становится NUMA: у каждого физического процессора свой домен, к которому прицеплены свои блоки памяти (DRAM модули). А переход между доменами заметно дороже, чем запросы в пределах одного домена, грузится мост, торможение на этом.
Возможно, к этому варианту с раздельными "камнями" ещё придут. Но не в пару ближайших лет. Сейчас бы освоить то, что натворили в пределах одного процессора.
Здравствуйте, Stanislaw K, Вы писали:
SK>>>значит процессор можно произвольно (относительно) переконфигурировать как хочешь.
C>>В очень узких пределах. C>>Переконфигурировать как хочешь — это может делать FPGA, но в процессоре ничего подобного нет.
SK>Микрокод определенно имеет достаточно свободы.
См. рядом. Ты думаешь, что "микрокод" в понятии современных процессоров это то, что определяет всю их работу до мельчайших деталей и его заменой можно сменить всю систему команд. Это не так.
C>>Именить его логику нельзя. SK>Помнится мне, пару раз что-то такое фиксили.
В пределах дозволенной гибкости. Тоже расписал подробнее.
