Здравствуйте, student__, Вы писали:
__>Ну и очевидно, что каждый раз перед запуском кода выбирать максимально производительный режим через винду (пусть даже по комбинации клавиш) — не вариант.
__>Что думаете по этому поводу?
Что идея "экономичных" ядер для десктопа — неправильная.
Здравствуйте, student__, Вы писали:
__>На сколько я понял, поддержка Intel Thread Director в 10 неполная, в отличие от 11. __>Что думаете по этому поводу?
Думаю, что Интел свернул куда-то не туда. AMD это на данный момень более стабильная платформа, без загонов с thread director, деградаций кристаллов и утраты HyperThreading.
Здравствуйте, rFLY, Вы писали:
A>>Что идея "экономичных" ядер для десктопа — неправильная. FLY>Так проблема не только в потреблении, но и с отводом тепла.
И чё? Эта проблема всегда была. Надо решать её другим (не таким странным) способом.
Здравствуйте, 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>При этом не тратил ни одного лишнего такта на лишнюю работу.
Это что означает, как понимать? Причём тут лишняя работа? Как определить что она лишняя?
Всё сказанное выше — личное мнение, если не указано обратное.
__>Т.е. если у вас ноут с маломальски свежим (в смысле "не протухшим") процем Intel
В смысле, процы intel теперь официально скоропортящийся товар, и успеть поставить винду до деградации нужно ещё постараться?
Здравствуйте, Alekzander, Вы писали:
A>Здравствуйте, rFLY, Вы писали: A>Кулером.
Как легко оказывается — ставишь кулер и сколько бы проц не жрал, температура будет в норме. Жаль инженерам интела никто это не подсказал.
Здравствуйте, rFLY, Вы писали:
A>>Кулером. FLY>Как легко оказывается — ставишь кулер и сколько бы проц не жрал, температура будет в норме. Жаль инженерам интела никто это не подсказал.
"Инженеры" (если ЭТО инклюзивное говно всё ещё можно назвать инженерами) интела хотели, чтобы их камни снова ставили в макбукоподобные стекляшки без охлаждения. А потеряли всех оставшихся покупателей. Все адекаты давно и прочно перешли на АМД.
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, Артём, Вы писали:
Аё>Думаю, что Интел свернул куда-то не туда. AMD это на данный момень более стабильная платформа, без загонов с thread director, деградаций кристаллов и утраты HyperThreading.
HyperThreading нафиг не нужон. Это изначально костыль, позволявший более плотно загрузить конвейеры суперскалярных процессоров. Когда он появился, блок предсказаний был ещё не столь совершенным, из-за чего большая часть конвейеров частенько проставляла. Да и существовавшие тогда компиляторы знали о скалярной архитектуре, но в суперскалярную не умели. Тащемта я однажды погрузился в эту тему: охренел от сложности задач оптимизации под суперскаляр.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, rm2, Вы писали:
rm2>потому что когда там фпс 300 или 450 — пофиг, а вот то что температура градусов на 20 больше стала — то заметно стало
Ну и логика у тебя. Фпс стал выше — пофиг, зато греется сильнее — это вроде как лучше стало
Здравствуйте, mike_rs, Вы писали:
_>с моего дивана видится, что должна быть некая прагма компилятора, типа поток емкий/лайтовый/фоновый/критический и т.п. И компилятор уже спец командами это объяснит процессору, под который идет сборка.
Ну вот этот набор понятий надо как-то выработать (или слямзить откуда-то). Он должен быть достаточно всеобъемлящим, чтобы все же существующие системы и системы обозримого будущего им более-менее описывались, но не черезчур, иначе им пользоваться будет невозможно.
A>>И чё? Зачем тут нужны хилые "экономичные" ядра? Почему их нельзя заменить одним нормальным ядром?
Ф>Чтобы на них упала некритичная фоновая нагрузка, очевидно же, что ядра "экономичные" — электричество экономят т.е.
Ну и как они его экономят-то? Просто медленно работают? Ну пусть нормальные ядра тоже медленно работают.
Чудес же не бывает. Если нужно сложить два числа, то их нужно сложить.
Здравствуйте, Философ, Вы писали:
A>>Ну и как они его экономят-то? Просто медленно работают? Ну пусть нормальные ядра тоже медленно работают. A>>Чудес же не бывает. Если нужно сложить два числа, то их нужно сложить.
Ф>Твоё "сложить 2 числа" по огромному конвейеру проходит, пока наконец исполнится. От длинны и сложности этого конвейера, от блоков на этом конвейере и зависит то как быстро оно исполнится и сколько энергии потребует в конечном счёте.
Я участвовал в проектировании отечественного процессора, и знаю в подробностях, как это всё работает.
Так в чём разница между быстрыми и экономичными ядрами? Ведь всё это всё равно надо сделать.
Ф>ЗЫ: У меня слегка подгорает, когда прогер с оргомным опытом говорит про "просто ложить 2 числа"....
Я не говорил, что нужно "просто сложить два числа". Я сказал, что работа должна быть сделана.
Работа всех этих конвейеров должна быть сделана.
PS.
Наш процессор в экономичном режиме не занимался переупорядочиванием инструкций (и всякой другой фигнёй),
а просто замирал до тех пор, пока данные не приходили из памяти.
При этом не тратил ни одного лишнего такта на лишнюю работу.
И что мешало то же самое сделать Интелу?
Здравствуйте, 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 модули). А переход между доменами заметно дороже, чем запросы в пределах одного домена, грузится мост, торможение на этом.
Возможно, к этому варианту с раздельными "камнями" ещё придут. Но не в пару ближайших лет. Сейчас бы освоить то, что натворили в пределах одного процессора.
Аргумент против Windows 11, глобально очевидно все, что микрософт делает, становится все хужее и хужее... Даже их великая кнопка пуск уже стала полный отстой , чего уж про кёрнелы гутарить. Поди скопипастили код интела для новых процов, попутно нагородив -дцать разных уровней софта, добавили по вкусу защиту а также защиту от защиты, менеджеры потоков и ядер, и увеличили обьем передачи данных пользователей в микрософт. Не факт что это все сразу заработает а не после N-й заплатки и апдатки. Помнится недавно был в сети уничижительный камент бывшего микрософта по поводу того как супер-быстро супер-новая-венда у него работает, вроде бы кнопка пуск открывается со скрипом даже на i9. Да там похоже диаспора индусов нанимает по знакомству еще больше новых индусов. Ви только посмотрите кто ходит по улицам Редмонда а там еще и аутсорс.
Здравствуйте, rFLY, Вы писали:
A>>И чё? Эта проблема всегда была. Надо решать её другим (не таким странным) способом. FLY>Каким, тротлингом?
Кулером.
Имея условно-бесконечное количество энергии из розетки, можно тратить её на перекачку тепла или охлаждение.
Эта тупость пришла из мира ARM, где кулеры ставить не принято.
Забавно, кстати, было, когда программисты, привыкшие к православному десктопу, в упор не врубались, что многоядерность ARM'а это не способ повысить вычислительную мощность (как на Пентиуме), а способ сэкономить батарейку. Теперь вот эта беда до нас добралась.
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, Pzz, Вы писали:
Pzz>И если честно, я не понимаю, по каким кретериям планировщик должен выбирать быстрое или экономичное ядро.
В чистом виде планировщик это сделат не в состоянии по определению. Нужна помощь со стороны разработки, тэгирование потока при создании и т.п. Но никто не будет этим заморачиватся. В итоге лотерея с пеерменным успехом.
В целом все это просто топтание на месте, попытка выдавить хоть что-то что маркетологи смогут продать.
Здравствуйте, alpha21264, Вы писали:
A>Здравым смыслом
Здравый смысл как раз таки подсказывает, что правильная: дофига софта лупят в один поток. Например, мой "горячо любимый" WinDbg c расширениями типа SoS именно такой, а провести там можно весь день, а потом он ещё ночь (всю) он будет GCRoot выводить.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Alekzander, Вы писали:
A>Главное, ещё раз, зачем даже в принципе иметь возможность просадки производительности, если у тебя комп работает от розетки? Экономичное ядро разве будет дешевле?
Не знаю, сделали ли это конкретно у Intel и AMD, но да, экономичное ядро можно сделать дешевле с точки зрения финальных затрат энергии на одну операцию, и методы для этого известны уже лет 40, со времён разделения CMOS и n-MOS. Или 60, если считать от появления ЭСЛ.
И это если не считать ещё игр по множеству параметров типа размеров кэшей и длины конвейера OoO, где есть множество затрат, которые растут сверхлинейно с ростом производительности.
__>Что думаете по этому поводу?
Концепция разных по производительности ядер требует от самого софта указывать какой тип ядра на данный момент нужен коду.
И вот фигня — это нигде на уровне языка не реализовано — поэтому и не работает как положено.
Введенный в ОС "интеллектуальный" помогатор наделен интеллектом улитки и не наделен телепатией,
поэтому потоки работающие в стиле "то пусто — то густо" всегда будут провисать и бесить пользователя неисправимыми тормозами.
На текущий момент "экономичные" ядра — маркетинговый мусор вызывающий случайные тормоза и фризы и не повышающий производительность.
Здравствуйте, Teolog, Вы писали:
T>Концепция разных по производительности ядер требует от самого софта указывать какой тип ядра на данный момент нужен коду. T>И вот фигня — это нигде на уровне языка не реализовано — поэтому и не работает как положено.
А с чего вдруг на уровне языка!? На кой ляд вообще в язык тянуть то, что не относится к написанию алгоритмов или описанию структур данных?
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
Ф>Можно делать энергоэффективно, как в Атомах, или максимально быстро как в производительных ядрах. Тащемта микроархитектура Gracemont — наследница микроархитектуры атомов. Ф>Я в предыдущем сообщении уже писал где отличия могут быть. Чтобы полностью описать разницу между Golden Cove и Gracemont, нужно сюда почти полностью скопировать документацию. Можно более кратко — посмотреть на блок-схему этих ядер.
Для меня процессор "черный ящик" и я по ламерски спрошу.
1) там же внутри микрокод. когда интел\амд выпускает "неудачный" процессор, они рассылают патчи микрокода для исправления ошибок и таки исправляют. да?
значит процессор можно произвольно (относительно) переконфигурировать как хочешь.
(кстати — интересный вектор атаки, когда компы вероятного противника начинают считать 2+2 = 4.003)
2) борьба за энергоэффективность ведется давно, и давно уже есть процы которые могут понижать или повышать частоту ядер внутри себя / шины снаружи.
Вопрос первый: что мешает сейчас делать все ядра одинаковыми и переконфигурировать их (часть из них) "на лету" под текущие задачи?
Если уж не хочется "на лету" переконфигурировать ядра Второй вопрос: раньше было true SMP, с несколькими физическими cpu. что этому мешает сейчас? запаять на материнку _И_ atom n100 в роли энергоэффективного, _И_ Core i9 ?
задачи они будут решать разные, кэши level1 level2 и даже level3 не пересекаются.
Несмотря на вроде как субъективно меньшую отзывчивость Windows 11 по сравнению с 10 на том же железе, 11 таки может быть более выгодна, и вот, по какой причине.
Если у вас ИНтел.
На сколько я понял, поддержка Intel Thread Director в 10 неполная, в отличие от 11.
Т.е. если у вас ноут с маломальски свежим (в смысле "не протухшим") процем Intel, т.е. начиная с 12го поколения, и если у вас режим нагрузки на ноут обычный для программистов —
"подправил код [ -> скомпилировал ] -> выполнил — виндовый планировщик в 10 будет ошибаться, назначать P-ядра задачам с печатью текста и C-ядра задачам с копиляцией и/или выполнением. А это негативно скажется на время атономной работы и шум вентиляторов (непредсказуемый).
Ну и очевидно, что каждый раз перед запуском кода выбирать максимально производительный режим через винду (пусть даже по комбинации клавиш) — не вариант.
Здравствуйте, alpha21264, Вы писали:
A>Что идея "экономичных" ядер для десктопа — неправильная.
Так проблема не только в потреблении, но и с отводом тепла.
Здравствуйте, student__, Вы писали:
__>Что думаете по этому поводу?
Думаю что фигня это все. Сижу на 13900k на десятке. Все процессы прежде всего падают на P ядра. Очень, очень, очень редко бывают случаи когда какая нибудь считалка не видит P ядра, и считает только на E ядрах.
По сути, под win10 P ядра для планировщика — это просто "лучшие ядра". Также и АМДешные ядра ранжируются.
А вот в w11 — там да, там есть этот трид директор, который не на лучшие ядра все кидает, а как то там пытается в зависимости от типа процесса их распределять, аля фоновые на E ядра, и всякое такое.
Здравствуйте, Pzz, Вы писали:
Pzz> Интересно, а для чего вообще она правильная?
Для девайсов с батарейкой.
Pzz> И если честно, я не понимаю, по каким кретериям планировщик должен выбирать быстрое или экономичное ядро.
Например, ориентируясь на время активности и время проведенное на объектах ожидания, на приоритет, в конце-концов у планировщика может быть некоторая статистика активности (спит на таймере, пробуждаясь время от времени)
Здравствуйте, rudzuk, Вы писали:
R>Для девайсов с батарейкой.
На самом деле, для любых задач, где нужен параллелизм. Если вместо нескольких быстрых ядер потратить тот же транзисторный и тепловой бюджет на медленные, то суммарная вычислительная мощность будет больше.
Здравствуйте, Codealot, Вы писали:
C>Здравствуйте, Артём, Вы писали:
Аё>>утраты HyperThreading.
C>Вот уж чего не будет жалко. В лучшем случае прирост от него копеечный, а в худшем — отрицательный. C>И точно так же проблемы с планированием тредов
Да брось. в куче задая аля рендера прирост в десятки процентов.
Здравствуйте, Codealot, Вы писали:
C>Здравствуйте, rm2, Вы писали:
rm2>>Да брось. в куче задая аля рендера прирост в десятки процентов.
C>Может быть, где-то они есть. Но у меня таких задач никогда не было C>Точно в десятки, а не в один десяток?
Здравствуйте, Codealot, Вы писали:
C>транзисторный и тепловой бюджет
Это неправильная модель. Правильная — пиковая производительность. Любой планировщик бюджетов от неё хоть что-то, да откусит, а теперь ещё выясняется, что нужна поддержка со стороны ОС.
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, Alekzander, Вы писали:
A>Правильная — пиковая производительность. Любой планировщик бюджетов от неё хоть что-то, да откусит, а теперь ещё выясняется, что нужна поддержка со стороны ОС.
То есть, чуть больше 20%. Ок.
Правда, рендеринг нужен примерно так 0.01% реальных пользователей.
rm2>да и даже в играх есть разница, если ядер игре не хватает реальных, то на реальных + HT есть хороший прирост. rm2>Вот например, смотреть 6c/12t и 6c/6t.
А вот это выглядит сомнительно, потому что с максимальными настройками должно упираться в видеокарту, а не процессор.
Здравствуйте, Codealot, Вы писали:
C>Здравствуйте, rm2, Вы писали:
rm2>>ну вот тут например: rm2>>https://www.phoronix.com/review/amd-ryzen-zen5-smt/4
C>То есть, чуть больше 20%. Ок. C>Правда, рендеринг нужен примерно так 0.01% реальных пользователей.
там не только рендеринг, почитай. там и 30% в какихто задачах есть.
C>А вот это выглядит сомнительно, потому что с максимальными настройками должно упираться в видеокарту, а не процессор.
ну представь что у тебя 4090. на кой ты сейчас про видеокарту сказал? Факт в том, что если игре не хватает реальных ядер — если есть ht ядра — игра начинает работать прилично быстрей.
Все же зависит от загрузки исполнительных устройств. если ПО такое что принципиально не умеет работать на максимум IPC реального ядра, и часть устройств простаивает — если загрузить эти устройства другим потоком — будет ускорение.
про игры — после перехода с 5090 на 13900 — у меня видеокарта стала сильней греться. потому что более быстрый процессор стал ее нагружать сильней.
Здравствуйте, mike_rs, Вы писали:
Pzz>>И если честно, я не понимаю, по каким кретериям планировщик должен выбирать быстрое или экономичное ядро.
_>В чистом виде планировщик это сделат не в состоянии по определению. Нужна помощь со стороны разработки, тэгирование потока при создании и т.п. Но никто не будет этим заморачиватся. В итоге лотерея с пеерменным успехом.
Нету внятной модели, чтобы этим заморачиваться. Я, например, как разработчик, не знаю, что выгоднее, прокрутить ту или иную активность по-быстрому на быстром ядре или на большее время занять медленное ядро. Как мне понять, в каком случае я потрачу меньше электричества? И не изменится ли выбор на следующей модели процессора?
_>В целом все это просто топтание на месте, попытка выдавить хоть что-то что маркетологи смогут продать.
Ну оно, конечно, на свежем процессоре машинка-то повеселее будет, чем на процессоре сколько-то там летней давности. Куда-то прогресс определенно идет.
Здравствуйте, Aquilaware, Вы писали:
A>При выполнении юнит тестов и тестов интеграции, прирост от HT почти 200%. Совсем не копеечный.
Разве HT — это не когда простаивающему блоку процессора, специализирующемся на выполнении одних задач, дают решать, пусть и менее эффективно, другие, т.к. блок, который разработан для их решения, занят. А у тебя прирост 200%. Или это не так работает?
Здравствуйте, rFLY, Вы писали:
FLY>Здравствуйте, Aquilaware, Вы писали:
A>>При выполнении юнит тестов и тестов интеграции, прирост от HT почти 200%. Совсем не копеечный. FLY>Разве HT — это не когда простаивающему блоку процессора, специализирующемся на выполнении одних задач, дают решать, пусть и менее эффективно, другие, т.к. блок, который разработан для их решения, занят. А у тебя прирост 200%. Или это не так работает?
HT — это когда есть SIMD-модуль, способный за 1 такт перемножать 4 пары 64-разрядных чисел, но ему на вход подаётся поток скалярных инструкций. И автопараллелизация не справляется с его загрузкой, так что одновременно выходит делать 1-2 операции. Зато рядом есть простаивающий thread, у которого свой поток скалярных инструкций. Ну, вот ему и можно отдать простаивающим АЛУ. Это не полноценное ядро, но лучше, чем ничего.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, rm2, Вы писали:
rm2>там не только рендеринг, почитай. там и 30% в какихто задачах есть.
Ага, еще там есть фракталы.
rm2>ну представь что у тебя 4090. на кой ты сейчас про видеокарту сказал? Факт в том, что если игре не хватает реальных ядер — если есть ht ядра — игра начинает работать прилично быстрей.
На той, что когда игре не хватает процессора — очень редкий случай.
Что касается 4090, то в 4K с высокими настройками и рейтрейсингом и она станет узким местом.
rm2>про игры — после перехода с 5090 на 13900 — у меня видеокарта стала сильней греться. потому что более быстрый процессор стал ее нагружать сильней.
Или просто потому, что 13900 и сам жарит корпус со страшной силой.
Здравствуйте, Codealot, Вы писали:
C>Или просто потому, что 13900 и сам жарит корпус со страшной силой.
нет. у меня корпус открытого типа, там никакой жары не задерживается.
просто процессор стал быстрее, стал быстрее кадр готовить, перестал быть узким горлышком — и быстрая видеокарта стала больше кадров выдавать. как итог — стала сильней греться.
Здравствуйте, Alekzander, Вы писали:
A>Это неправильная модель. Правильная — пиковая производительность. Любой планировщик бюджетов от неё хоть что-то, да откусит, а теперь ещё выясняется, что нужна поддержка со стороны ОС.
Для любого процессора нужна поддержка OS. Например, для того чтобы сохранить состояния регистров в контекст потока. Появляется SSE — нужна поддержка XMM, появляется AVX — нужна поддержка YMM, AVX512 — теперь нужно ZMM поддерживать. Более того, если твоя ось не поставит флажок, что она умеет в SSE, то любая SSE инструкция свалится с illegal instruction. Это почти со всеми расширениями.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
A>>Это неправильная модель. Правильная — пиковая производительность. Любой планировщик бюджетов от неё хоть что-то, да откусит, а теперь ещё выясняется, что нужна поддержка со стороны ОС.
Ф>Для любого процессора нужна поддержка OS. Например, для того чтобы сохранить состояния регистров в контекст потока. Появляется SSE — нужна поддержка XMM, появляется AVX — нужна поддержка YMM, AVX512 — теперь нужно ZMM поддерживать. Более того, если твоя ось не поставит флажок, что она умеет в SSE, то любая SSE инструкция свалится с illegal instruction. Это почти со всеми расширениями.
И зачем нам сравнивать экономичные ядра и новые наборы команд?
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, Alekzander, Вы писали:
A>И зачем нам сравнивать экономичные ядра и новые наборы команд?
Затем, что на этом примере хорошо видно, что любое или почти любое расширение процессора требует поддержки OS. Сейчас мне только одно исключение известно: 3dNow!
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
A>>И зачем нам сравнивать экономичные ядра и новые наборы команд? Ф>Затем, что на этом примере хорошо видно, что любое или почти любое расширение процессора требует поддержки OS. Сейчас мне только одно исключение известно: 3dNow!
Ну написано же: если нужна высокая пиковая производительность (как обычно на десктопах), добавление таких ядер её ухудшит **И** вдобавок потребует поддержки ОС.
Можно просто не покупать ни эти новые процессоры, ни эти новые винды.
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, Alekzander, Вы писали:
A>Ну написано же: если нужна высокая пиковая производительность (как обычно на десктопах), добавление таких ядер её ухудшит
Здравствуйте, Codealot, Вы писали:
A>>Ну написано же: если нужна высокая пиковая производительность (как обычно на десктопах), добавление таких ядер её ухудшит
C>Каким образом?
А ты думаешь, такой планировщик сможет работать на 100% эффективно? Не допуская, даже временно, выделения требовательному потоку эконом-ядра?
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, Alekzander, Вы писали:
A>А ты думаешь, такой планировщик сможет работать на 100% эффективно? Не допуская, даже временно, выделения требовательному потоку эконом-ядра?
Нетривиально, но не вижу принципиальных препятствий.
Для сравнения, в случае гипер-трединга избавиться от проблемы просадок скорости невозможно в принципе
Здравствуйте, Codealot, Вы писали:
A>>А ты думаешь, такой планировщик сможет работать на 100% эффективно? Не допуская, даже временно, выделения требовательному потоку эконом-ядра?
C>Нетривиально, но не вижу принципиальных препятствий.
А я не вижу зачем вообще это надо на десктопе.
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, Alekzander, Вы писали:
A>А ты думаешь, такой планировщик сможет работать на 100% эффективно? Не допуская, даже временно, выделения требовательному потоку эконом-ядра?
Ну а почему нет!? Может работать на 100% эффективно, если будет считать нетребовательными потоки, которые более трёх квантов подряд отработали менее чем за четверть кванта: переключение контекта больше чем разница в работе на разных ядрах, или уже 10 минут подряд висят на мьютексе или спин-локе.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Alekzander, Вы писали:
A>А я не вижу зачем вообще это надо на десктопе.
PS я просто офигеваю от здешней публики. Ругают PE ядра за все те же недостатки что есть и у HT, но при этом хвалят HT. Более того — не понимают, что у HT есть серьезные недостатки, которых у PE нет.
Здравствуйте, Философ, Вы писали:
A>>А ты думаешь, такой планировщик сможет работать на 100% эффективно? Не допуская, даже временно, выделения требовательному потоку эконом-ядра?
Ф>Ну а почему нет!? Может работать на 100% эффективно, если будет считать нетребовательными потоки, которые более трёх квантов подряд отработали не использовали более чем на четверть, или уже 10 минут подряд висят на мьютексе или спин-локе.
Звучит красиво, только в реальности есть, допустим, 4+4 ядра и этак с тысячу потоков. И они, собаки, в твои простые эвристики не укладываются. Закончится всё, как на картинке:
Главное, ещё раз, зачем даже в принципе иметь возможность просадки производительности, если у тебя комп работает от розетки? Экономичное ядро разве будет дешевле?
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, Codealot, Вы писали:
A>>А я не вижу зачем вообще это надо на десктопе.
C>Добавочная скорость в многопотоке при том же транзисторном и тепловом бюджете, а избавление от гипертрединга улучшает однопоток и латентность.
Гипертрединг и экономичные ядра — это взаимоисключающие вещи? Или тебе просто настолько нравится слово "гипетрединг", что ты его вставляешь в каждый пост?
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, Alekzander, Вы писали:
A>Гипертрединг и экономичные ядра — это взаимоисключающие вещи?
Если очень любишь проблемы — то нет, не взаимоисключающие.
A>Или тебе просто настолько нравится слово "гипетрединг", что ты его вставляешь в каждый пост?
Здравствуйте, Alekzander, Вы писали:
A>Главное, ещё раз, зачем даже в принципе иметь возможность просадки производительности, если у тебя комп работает от розетки?
Значит, гипертрединг не нужен.
A>Экономичное ядро разве будет дешевле?
Да, вычислительная мощность в такой форме дешевле. В этом весь смысл.
Все еще не дошло?
Здравствуйте, Pzz, Вы писали:
Pzz>Нету внятной модели, чтобы этим заморачиваться. Я, например, как разработчик, не знаю, что выгоднее, прокрутить ту или иную активность по-быстрому на быстром ядре или на большее время занять медленное ядро. Как мне понять, в каком случае я потрачу меньше электричества? И не изменится ли выбор на следующей модели процессора?
с моего дивана видится, что должна быть некая прагма компилятора, типа поток емкий/лайтовый/фоновый/критический и т.п. И компилятор уже спец командами это объяснит процессору, под который идет сборка.
Здравствуйте, mike_rs, Вы писали: _>с моего дивана видится, что должна быть некая прагма компилятора, типа поток емкий/лайтовый/фоновый/критический и т.п. И компилятор уже спец командами это объяснит процессору, под который идет сборка.
Не процессору, а операционной системе, и сдаётся мне, что рулить этим всем придётся всё-таки руками:
пример руления (копипаста из MSDN'а
THREAD_POWER_THROTTLING_STATE PowerThrottling;
ZeroMemory(&PowerThrottling, sizeof(PowerThrottling));
PowerThrottling.Version = THREAD_POWER_THROTTLING_CURRENT_VERSION;
//
// EcoQoS
// Turn EXECUTION_SPEED throttling on.
// ControlMask selects the mechanism and StateMask declares which mechanism should be on or off.
//
PowerThrottling.ControlMask = THREAD_POWER_THROTTLING_EXECUTION_SPEED;
PowerThrottling.StateMask = THREAD_POWER_THROTTLING_EXECUTION_SPEED;
SetThreadInformation(GetCurrentThread(),
ThreadPowerThrottling,
&PowerThrottling,
sizeof(PowerThrottling));
//
// HighQoS
// Turn EXECUTION_SPEED throttling off.
// ControlMask selects the mechanism and StateMask is set to zero as mechanisms should be turned off.
//
PowerThrottling.ControlMask = THREAD_POWER_THROTTLING_EXECUTION_SPEED;
PowerThrottling.StateMask = 0;
SetThreadInformation(GetCurrentThread(),
ThreadPowerThrottling,
&PowerThrottling,
sizeof(PowerThrottling));
//
// Let system manage all power throttling. ControlMask is set to 0 as we don’t want
// to control any mechanisms.
//
PowerThrottling.ControlMask = 0;
PowerThrottling.StateMask = 0;
SetThreadInformation(GetCurrentThread(),
ThreadPowerThrottling,
&PowerThrottling,
sizeof(PowerThrottling));
Очевидно же, что для программы может меняться требованияк скорости вычислителя для потока. Так же очевидно, что поток — объект ядра, и создавать его очень дорого — нужно реиспользовать уже созданные.
Здравствуйте, Философ, Вы писали:
A>>Здравым смыслом
Ф>Здравый смысл как раз таки подсказывает, что правильная: дофига софта лупят в один поток. Например, мой "горячо любимый" WinDbg c расширениями типа SoS именно такой, а провести там можно весь день, а потом он ещё ночь (всю) он будет GCRoot выводить.
И чё? Зачем тут нужны хилые "экономичные" ядра? Почему их нельзя заменить одним нормальным ядром?
Здравствуйте, netch80, Вы писали:
A>>Главное, ещё раз, зачем даже в принципе иметь возможность просадки производительности, если у тебя комп работает от розетки? Экономичное ядро разве будет дешевле?
N>дешевле с точки зрения финальных затрат энергии на одну операцию
Я, если что, говорил про деньги.
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, alpha21264, Вы писали:
A>Ну и как они его экономят-то? Просто медленно работают? Ну пусть нормальные ядра тоже медленно работают. A>Чудес же не бывает. Если нужно сложить два числа, то их нужно сложить.
Твоё "сложить 2 числа" по огромному конвейеру проходит, пока наконец исполнится. От длинны и сложности этого конвейера, от блоков на этом конвейере и зависит то как быстро оно исполнится и сколько энергии потребует в конечном счёте.
Смотри:
Прежде чем сложить 2 числа, нужно сначала взять инструкцию из память (The Fetch/Decode Unit), потом распознать инструкцию задействовав там же Instruction Decoder или Simple Instruction Decoder, потом обратиться к таблице алиасов регистров (Register Alias Table), потом загнать эту инструкццию в Reorder Buffer, и только потом Retirement Unit может взять оттуда микрооперации и загнать их Integer Unit, который наконец-то сможет сложить два числа. А потом ещё вопрос, что с результатом делать — всё осложняет Register Alias Table.
Это самый-самый минимум, который я выдрал из спецификации к Pentium Pro, притом не всё оттуда переписал. Т.е. не просто так сложить. Это для тебя это выглядит как
add eax, ebx
под капотом всё немного сложнее.
Из того, что я намеренно пропустил в тут — Dispatch/Execute Unit. Это именно та штука, которая выбирает из буфера перестановок микрооперации. Он может быть очень сильно разным, как и колличество исполнительных блоков. Например, в NetBurst этот блок в мануале уже называется "The out-of-order execution core" и он уже содержит несколько буферов переупорядочивания . В Pentium Pro (во всей P6) 5 исполнительных блоков: 2 целочисленных юнита, 2 плавающей точки и один memory-interface юнит. NetBurst уже за так умеет 6 операций диспатчить, притом его 3 АЛУ работают на удвоенной частоте ядра.
Очевидно, что колличество исполнительных блоков может быть сильно разным и работать они могут очень по разному, и устроены могут быть по-разному: могут быть отдельно целочисленные юниты и юниты плавающей точки, а могут быть обобщённые ALU, которые в добавок элементарные целочисленные операции за половину такта выполняют.
А кроме есть, есть ещё много много всякого, в котором я до конца не разобрался и где подробностей не знаю, однако они тоже участвуют в исполнении, тоже влияют на скорость исполнения и в конечном счёте на сожранную в процессе энергию. Это например целевые буферы ветвлений (B ranch Target Buffers), кэши трассировки и блок предсказания переходов (в документации — branch prediction hardware). И ещё много-много чего, что пролетело мимо моего внимания, просто потому что я разбирался только с оптимизацией кода, а не процессор проектировал. Всё это учавствует в "сложить 2 числа".
ЗЫ: У меня слегка подгорает, когда прогер с оргомным опытом говорит про "просто ложить 2 числа"....
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, 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>>>значит процессор можно произвольно (относительно) переконфигурировать как хочешь.
C>>В очень узких пределах. C>>Переконфигурировать как хочешь — это может делать FPGA, но в процессоре ничего подобного нет.
SK>Микрокод определенно имеет достаточно свободы.
См. рядом. Ты думаешь, что "микрокод" в понятии современных процессоров это то, что определяет всю их работу до мельчайших деталей и его заменой можно сменить всю систему команд. Это не так.
C>>Именить его логику нельзя. SK>Помнится мне, пару раз что-то такое фиксили.
В пределах дозволенной гибкости. Тоже расписал подробнее.
