Здравствуйте, 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 модули). А переход между доменами заметно дороже, чем запросы в пределах одного домена, грузится мост, торможение на этом.

Возможно, к этому варианту с раздельными "камнями" ещё придут. Но не в пару ближайших лет. Сейчас бы освоить то, что натворили в пределах одного процессора.