Это увлечение diversity заканчивается тем, что главную эйчарку назначают руководить DCAI: https://www.intel.com/content/www/us/en/newsroom/biographies/biography-sandra-l-rivera.html
Может иметь значение на тяжёлых enterprise приложениях, когда icache/itlb миссы отъедают значительную часть времени.
Возможно, ошибаюсь, но мне всегда казалось, что icache или itlb miss случится только если переход не предсказался, и при этом branch target далеко относительно инструкции перехода. Всё таки instruction fetch работает спекулятивно. Скорее это будет, на indirect call/jump, и с этим надо бороться девиртуализацией методов.
push/pop - две load/store операции с зависимостью
Если мне память не изменяет, то в том же golden cove сделали memory renaming как раз для такого. Но это только пытается порвать зависимость по данным, store и load всё равно выполняются, травят кэш и греют атмосферу.
А теперь давайте считать, сколько обращений в память и арифметики требуют инструкции call и ret, как предсказываются переходы, и какое влияние всё это оказывает на исполнение кода. Нет, серьёзно, в Intel и AMD работают весьма грамотные инженеры, которые к тому же имеют доступ к деталям реализации процессоров. Так что платформоспецифичные оптимизации для x86 никто лучше них не реализует. Достаточно посмотреть, какой код генерируют GCC и llvm, для которых x86-специфичные вещи разработаны инженерами Intel, чтобы отпало всякое желание экспериментировать с 8 и 16-битной арифметикой, выравниванием, уплотнением кода, etc.
Только в реальности процессор регистры переименовывает. Все эти rax-r15 в некотором роде виртуальные. В настоящем процессоре будет больше сотни регистров общего назначения. Что касается плотности кода, то больше 32 байт и 5 инструкций за такт всё равно не декодируется, поэтому слишком уж уплотнять тоже нет смысла.
Почему-то у меня в документе написано другое: "Scalar floating-point SIMD instructions have lower latencies than equivalent x87 instructions. Scalar SIMD floating-point multiply instruction may be pipelined, while x87 multiply instruction is not. Although x87 supports transcendental instructions, software library implementation of transcendental function can be faster in many cases."
SSE это ещё и скалярные операции. И прочитайте наконец интеловское руководство по оптимизации. Там чёрным по белому написано: не используйте инструкции x87 FPU, они медленные, и сохранены только для совместимости со старым софтом.
А теперь расскажите, как уволить человека, если он не хочет увольняться сам. По сокращению? Проблемно, потом замену не нанять. По несоответствию занимаемой должности? Не оформить. По соглашению сторон? Так он не хочет. Или требует в соглашении каких-то неадекватных выплат.
Выбросить инструкцию BOUND было очевидно хорошим решением по двум причинам: (1) она реализуется неприлично длинной последовательностью микрокода и (2) компиляторы её не используют.
(1) легко заметить, если посмотреть на семантику. Как минимум, нужно две загрузки из памяти, два сравнения и условная генерация исключения. При этом, пользователь не может никак это оптимизировать, храня границы диапазона в регистрах. Плюс, генерация исключения сама по себе очень дорогая: сброс конвейера и туча обращений в память. Дешевле эту операцию сделать с помощью пары CMP и пары Jcc.
(2) в соответствии со стандартами языков C и C++, на которых пишут большинство критичного к производительности софта, выход за границы массива это неопределённое поведение. Соответственно, компилятор имеет право предполагать, что таких ситуаций в программе никогда не происходит. Следовательно, эти проверки просто не нужны. В частности, и GCC, и clang/llvm их вставляют только если очень хорошо попросить специальной опцией, и при этом часть оптимизаций идёт лесом.
Более того, архитектура x86 явно запрещает переупорядочивать операции чтения. То есть нельзя поменять местами два чтения или две записи. Можно только чтение и запись.
А как этот "комитет" предлагает тестировать подобные вещи, если не на животных?
Ну, ради справедливости, ещё не во всём интеле бранчи master переименовали, остались пока ещё адекватные менеджеры.
Я ни в коем случае не оспариваю. Но вроде бы во всех гайдлайнах по найму сказано, что нельзя предъявлять требования к полу и возрасту.
Это увлечение diversity заканчивается тем, что главную эйчарку назначают руководить DCAI: https://www.intel.com/content/www/us/en/newsroom/biographies/biography-sandra-l-rivera.html
Возможно, ошибаюсь, но мне всегда казалось, что icache или itlb miss случится только если переход не предсказался, и при этом branch target далеко относительно инструкции перехода. Всё таки instruction fetch работает спекулятивно. Скорее это будет, на indirect call/jump, и с этим надо бороться девиртуализацией методов.
Если мне память не изменяет, то в том же golden cove сделали memory renaming как раз для такого. Но это только пытается порвать зависимость по данным, store и load всё равно выполняются, травят кэш и греют атмосферу.
А теперь давайте считать, сколько обращений в память и арифметики требуют инструкции call и ret, как предсказываются переходы, и какое влияние всё это оказывает на исполнение кода. Нет, серьёзно, в Intel и AMD работают весьма грамотные инженеры, которые к тому же имеют доступ к деталям реализации процессоров. Так что платформоспецифичные оптимизации для x86 никто лучше них не реализует. Достаточно посмотреть, какой код генерируют GCC и llvm, для которых x86-специфичные вещи разработаны инженерами Intel, чтобы отпало всякое желание экспериментировать с 8 и 16-битной арифметикой, выравниванием, уплотнением кода, etc.
Только в реальности процессор регистры переименовывает. Все эти rax-r15 в некотором роде виртуальные. В настоящем процессоре будет больше сотни регистров общего назначения. Что касается плотности кода, то больше 32 байт и 5 инструкций за такт всё равно не декодируется, поэтому слишком уж уплотнять тоже нет смысла.
Почему-то у меня в документе написано другое: "Scalar floating-point SIMD instructions have lower latencies than equivalent x87 instructions. Scalar SIMD floating-point multiply instruction may be pipelined, while x87 multiply instruction is not. Although x87 supports transcendental instructions, software library implementation of transcendental function can be faster in many cases."
SSE это ещё и скалярные операции. И прочитайте наконец интеловское руководство по оптимизации. Там чёрным по белому написано: не используйте инструкции x87 FPU, они медленные, и сохранены только для совместимости со старым софтом.
А теперь расскажите, как уволить человека, если он не хочет увольняться сам. По сокращению? Проблемно, потом замену не нанять. По несоответствию занимаемой должности? Не оформить. По соглашению сторон? Так он не хочет. Или требует в соглашении каких-то неадекватных выплат.
IOMMU не пишет в память. Оно только адреса транслирует
Выбросить инструкцию BOUND было очевидно хорошим решением по двум причинам: (1) она реализуется неприлично длинной последовательностью микрокода и (2) компиляторы её не используют.
(1) легко заметить, если посмотреть на семантику. Как минимум, нужно две загрузки из памяти, два сравнения и условная генерация исключения. При этом, пользователь не может никак это оптимизировать, храня границы диапазона в регистрах. Плюс, генерация исключения сама по себе очень дорогая: сброс конвейера и туча обращений в память. Дешевле эту операцию сделать с помощью пары CMP и пары Jcc.
(2) в соответствии со стандартами языков C и C++, на которых пишут большинство критичного к производительности софта, выход за границы массива это неопределённое поведение. Соответственно, компилятор имеет право предполагать, что таких ситуаций в программе никогда не происходит. Следовательно, эти проверки просто не нужны. В частности, и GCC, и clang/llvm их вставляют только если очень хорошо попросить специальной опцией, и при этом часть оптимизаций идёт лесом.
Не получается из дурости извлечь полезную работу, так что увы (-:
Не получается. Квантовая механика не даёт бесконечно уменьшаться )-:
ТС просто описал своими словами вечный двигатель второго рода (-:
Эта "рециркуляция" возможна только с совершением работы, то есть с затратами энергии. Иначе нарушается второе начало термодинамики.
В общем-то opencl ± жив. И SPIR-V в нём тоже поддерживается.
Это очень похоже на модули из C++20
Очевидно, никакие
Более того, архитектура x86 явно запрещает переупорядочивать операции чтения. То есть нельзя поменять местами два чтения или две записи. Можно только чтение и запись.
Всё-таки ABI, а не API