ну такое...подобным приказам не первый год идет, но по факту бизнес, даже государев сопротивляется. Зачем боярину покупать каку, которая снижает эффективность бизнеса, когда можно купить леденец, заработать и украсть больше.
Я работал в какой то момент в конторе буржуйской известной американской сервера в том числе делает. Приходишь в какой нито банк щавелевого цвета, там тех директор говорит, мы бы и рады купить у вас, но тут вот царь не велит...импортозамещение и все такое....ну в итоге сервер собирается в стране, и становится российским) Даже писали одно время что основные комплектующие российские (мелким шрифтом - по массе)))))) шасси, крепеж, блок питания были наши (хотя покупали просто у наших поставщиков, а они совсем что то там мутили черное делая китай россией))))). Будут выкручивать руки с процами например, будет какой нито интел "финализировать корпусирование" в России....там этой казуистикой можно бесконечно заниматься. А там или ишак или подишах помрет. Любой бизнес он будет делать что угодно если это выгодно
Жизнь штука сложная. Даже безотносительно «хождения строем» в жизни много где нужно «тупо играть по правилам».
Вот хоть элементарно на релокацию документы подать (+ опционально пройти языковой тест… оп, а почему и здесь какие-то дурацкие тесты, да?), хоть сертификацию на CCIE, хоть устроиться в FAANG.
Вобщем, ЕГЭ проверяет не только знания, но и умение работать по «заданному внешне» workflow.
А в глубине души его вообще можно ненавидеть и после сдачи сразу пойти и работать как хочешь, хоть в тундре и без людей совсем.
Уехать из Европы в Анголу было лучшим решением в моей жизни
Хороший пример того, что называется "поход за славой": настоящий успех достигается не монотонной и долгой работой, а неким рискованным предприятием (чтоб не сказать авантюрой), дающим крутые бонусы относительно быстро. После чего можно и расслабиться. На время.
На самом деле техпроцессы у высокопроизводительных и энергоэффективных CPU одного класса, обычно, не отличаются. Транзисторы те же. Другое дело, что если в высокопроизводительных CPU часть транзисторов отвечают за повышение быстродействия (например, спекулятивное исполнение команд), то в энергоэффективных - за отключение питания неиспользуемых блоков и отказ от спекулятивного выполнения, как необоснованного расхода энергии.
Например, имеем такой код:
x = (f(a)>f(b)) ? a/b : a*b;
Высокопроизводительный CPU может выполнить обе операции умножения и деления параллельно еще до того, как будет определено, что нужно было выполнить только одну из них. Энергоэффективный CPU станет умножать или делить только после вычисления выражения f(a)>f(b), чтобы не тратить энергию на спекулятивные операции.
Пропускная способность памяти несильно. Там пакетная передача да и большая часть передачи — данные.
Средняя длина инструкции сейчас уже больше 4х байт вроде бы.
Кэш да, я об этом говорил. Но за счет этого вы можете упросить декодеры.
Ну с точки зрения архитектуры у нас сейчас все кратно 8.
Поскольку других нет, ограничить 16 байтами и пока забить. Преждевременная оптимизация.
А там, глядишь, будет очередная смена инструкций под названием super_128 или еще чего.
AMD_64 ведь тоже несовместима с более старыми системами.
Как минимум одно решение существует.
Можно создать формат исполняемого файла, в котором будут выровнены по 16байтовой границе не только данные, но и инструкции. Память при этом будет расходоваться неэффективно, но можно будет проще его разбирать.
Зачем? На старых процессорах это будет работать через инструкция+Noop X N до 15ти.
Перерасход памяти большой. И еще значительнее — перерасход кеша.
Но собственно при переходе на 64бит тоже средняя длина инструкции была значительно увеличена, в 1.8 раз вроде бы.
Изменения в ОС — минимальны. Изменения в процессоре — отдельная инструкция переключащая режим на «упрощенный». Сами декодеры, естественно, прийдется менять.
Да и вообще это вариант пришедший сразу, сходу. Думаю есть еще много других чуть более сложных решений.
Я как раз про распределение переменных по явно доступным регистрам. Меньше load store и потенциально меньше проблем в renaming. Что вы далее и написали.
Потенциально это не про hardware. Hardware должен умень кушать worst case который от количества регистров не меняется.
Количество регистров никак не позволяет делать алгоритмы в железе проще.
Я этого не говорил. Это бред.
Я как раз про распределение переменных по явно доступным регистрам. Меньше load store и потенциально меньше проблем в renaming. Что вы далее и написали.
Но действительно с тех пор больше не увеличивают. Значит смысла нет.
Хм, быть того не может. Зачем же в процессе увеличили количество явно доступных регистров?
Количество регистров никак не позволяет делать алгоритмы в железе проще. Если есть больше регистров, компилятор сможет ими пользоваться и хранить в них какие-то значения. Скорее всего это позволит сократить количество обращений к памяти потому что больше переменных можно будет просто хранить в регистрах. В результате код может будет немного оптимальнее. Но не факт, потому что существующие ABI требуют сохранять регистры в стек на входе в каждую функцию а потом восстанавливать на выходе, что тоже накладно.
Но да, в среднем количество LOAD и STORE на Arm в программах на Aarch64 процентов на 10 меньше, в основном благодаря 32 регистрам.
ну такое...подобным приказам не первый год идет, но по факту бизнес, даже государев сопротивляется. Зачем боярину покупать каку, которая снижает эффективность бизнеса, когда можно купить леденец, заработать и украсть больше.
Я работал в какой то момент в конторе буржуйской известной американской сервера в том числе делает. Приходишь в какой нито банк щавелевого цвета, там тех директор говорит, мы бы и рады купить у вас, но тут вот царь не велит...импортозамещение и все такое....ну в итоге сервер собирается в стране, и становится российским) Даже писали одно время что основные комплектующие российские (мелким шрифтом - по массе)))))) шасси, крепеж, блок питания были наши (хотя покупали просто у наших поставщиков, а они совсем что то там мутили черное делая китай россией))))). Будут выкручивать руки с процами например, будет какой нито интел "финализировать корпусирование" в России....там этой казуистикой можно бесконечно заниматься. А там или ишак или подишах помрет. Любой бизнес он будет делать что угодно если это выгодно
Вот хоть элементарно на релокацию документы подать (+ опционально пройти языковой тест… оп, а почему и здесь какие-то дурацкие тесты, да?), хоть сертификацию на CCIE, хоть устроиться в FAANG.
Вобщем, ЕГЭ проверяет не только знания, но и умение работать по «заданному внешне» workflow.
А в глубине души его вообще можно ненавидеть и после сдачи сразу пойти и работать как хочешь, хоть в тундре и без людей совсем.
Хороший пример того, что называется "поход за славой": настоящий успех достигается не монотонной и долгой работой, а неким рискованным предприятием (чтоб не сказать авантюрой), дающим крутые бонусы относительно быстро. После чего можно и расслабиться. На время.
Правило не универсально.
Поправка на ошибку выжившего обязательна.
Он выиграл ценой, но теперь и времена другие. Портировать софт сильно проще, а arm или risc-v будет едва ли дороже x86 аналога.
На самом деле техпроцессы у высокопроизводительных и энергоэффективных CPU одного класса, обычно, не отличаются. Транзисторы те же. Другое дело, что если в высокопроизводительных CPU часть транзисторов отвечают за повышение быстродействия (например, спекулятивное исполнение команд), то в энергоэффективных - за отключение питания неиспользуемых блоков и отказ от спекулятивного выполнения, как необоснованного расхода энергии.
Например, имеем такой код:
x = (f(a)>f(b)) ? a/b : a*b;
Высокопроизводительный CPU может выполнить обе операции умножения и деления параллельно еще до того, как будет определено, что нужно было выполнить только одну из них. Энергоэффективный CPU станет умножать или делить только после вычисления выражения f(a)>f(b), чтобы не тратить энергию на спекулятивные операции.
Дело не в максимальной производительности, а в производительности на Вт, об этом и надписано в тексте.
AWS выбрали то, что выгоднее, а значит x86 проиграл и потерял долю у гигантского клиента серверных CPU. И потеряет еще больше — уже вышел Graviton3.
Рынок оценивается не по стоимости устройства, а по выручке со всеми устройств. И рынок мобильных SoC гигантский по сравнению с десктопами и серверами.
Средняя длина инструкции сейчас уже больше 4х байт вроде бы.
Кэш да, я об этом говорил. Но за счет этого вы можете упросить декодеры.
Поскольку других нет, ограничить 16 байтами и пока забить. Преждевременная оптимизация.
А там, глядишь, будет очередная смена инструкций под названием super_128 или еще чего.
AMD_64 ведь тоже несовместима с более старыми системами.
Да, но только в x86 длина инструкции не ограниченна (хотя сейчас уже ограничили до 15 байт, но все же).
Можно создать формат исполняемого файла, в котором будут выровнены по 16байтовой границе не только данные, но и инструкции. Память при этом будет расходоваться неэффективно, но можно будет проще его разбирать.
Перерасход памяти большой. И еще значительнее — перерасход кеша.
Но собственно при переходе на 64бит тоже средняя длина инструкции была значительно увеличена, в 1.8 раз вроде бы.
Изменения в ОС — минимальны. Изменения в процессоре — отдельная инструкция переключащая режим на «упрощенный». Сами декодеры, естественно, прийдется менять.
Да и вообще это вариант пришедший сразу, сходу. Думаю есть еще много других чуть более сложных решений.
Потенциально это не про hardware. Hardware должен умень кушать worst case который от количества регистров не меняется.
Я как раз про распределение переменных по явно доступным регистрам. Меньше load store и потенциально меньше проблем в renaming. Что вы далее и написали.
Но действительно с тех пор больше не увеличивают. Значит смысла нет.
Количество регистров никак не позволяет делать алгоритмы в железе проще. Если есть больше регистров, компилятор сможет ими пользоваться и хранить в них какие-то значения. Скорее всего это позволит сократить количество обращений к памяти потому что больше переменных можно будет просто хранить в регистрах. В результате код может будет немного оптимальнее. Но не факт, потому что существующие ABI требуют сохранять регистры в стек на входе в каждую функцию а потом восстанавливать на выходе, что тоже накладно.
Но да, в среднем количество LOAD и STORE на Arm в программах на Aarch64 процентов на 10 меньше, в основном благодаря 32 регистрам.