Здесь вопрос о преимуществах в большей мере касается поддержки процессором широкого спектра ПО. Плюс еще несколько факторов: компактность, накопитель (он в Racing P1 не бог весть какой, но в комплекте) и потребляемая мощность. Вот это последнее подкупает, конечно, потому что меньше 5 Ватт (в режиме сна, правда, 2 Вт и не меньше).
Очень жаль, что питание Racing P1 не предусматривает использования USB Type-C. Внешний адаптер слегка напрягает. Понятно, что и для автономного питания через USB-C понадобится аналогичный. Но здесь возможны сюрпризы.
В предметной дискуссии лучше оперировать физическими величинами: гигабайтами в секунду, количеством тактов на инструкцию, в частности, — для описанных в статье 128-битных SSE-инструкций. Она ведь ориентирована на специалистов по низкоуровневой оптимизации программного обеспечения. Поэтому сознательно предпочли сферического коня рекламным лозунгам.
Идея понятна — располагаем исследуемую многобайтовую последовательность на границе страниц памяти, при этом вторая страница должна быть отмечена как отсутствующая, чтобы при попытке обращения к ней генерировался Page Fault. Пытаемся выполнить эту последовательность как инструкцию, ждем реакцию процессора и анализируем ее.
Если сгенерирован Page Fault (PF, vector 0Eh), значит исследуемая последовательность байтов является инструкцией, при этом ее часть «залезла» на вторую страницу, что позволяет сделать вывод о длине байтового представления инструкции.
Если вместо Page Fault генерируется General Protection Fault (GPF, vector 0Dh) или Invalid Opcode Exception (vector 06h), то это значит, что байтов, расположенных в первой странице, процессору достаточно, чтобы «понять» что операция недопустима, «понять» до попытки адресации второй страницы.
Когда-то делали что-то подобное под DOS для поиска недокументированных MSR. Но там все было значительно проще:
Устанавливаем собственную процедуру обработки GPF (vector 0Dh)
Загружаем в ECX адрес исследуемого (якобы несуществующего) MSR
Выполняем инструкцию RDMSR
Если не генерируется General Protection Fault, значит этот MSR существует.
Делая тот же трюк с недокументированными кодами инструкций нет уверенности в том, что на любой недопустимый код операции процессор дисциплинированно сгенерирует #UD (vector 06h) или #GPF (vector 0Dh), в ходе исследования возможны зависания и рестарты, вероятность которых можно уменьшить, проводя исследования на виртуальной машине, что автор и сделал.
Дело не в содержании заполнителя (нули или другие данные), а в обеспечении условий, при которых процессор после записи располагает полной информацией о содержимом 64-байтной кэш-строки. Если строка перезаписана частично (записано менее 64 байт), то для получения содержимого не перезаписанной части строки требуется подгружать данные из ОЗУ, чтобы обеспечить достоверность всех 64 байт.
Если строка перезаписана полностью (записано 64 байта по адресу кратному 64), то исходное содержимое ОЗУ можно проигнорировать, так как оно полностью «перекрыто» новыми данными и содержимое кэш-строки является функцией только данных записи и не является функцией исходного содержимого ОЗУ.
Такой метод обслуживания записи без обращения к ОЗУ, экономит не только такты, но и потребляемую мощность. Да, верно подмечено, у процессоров Intel, поддерживающих AVX512, инициировать 64-байтную запись можно и без CLZERO инструкцией записи, например, VMOVAPD [rax],zmm0. Такой подход работает для 64-байтных кэш-строк (512 бит = 64 байта), но пока нет оснований полагать, что размер кэш-строк изменится в новых процессорах. Или есть?
Согласно Intel Xeon Phi System Software Developer Guide, если на новом процессоре, не поддерживающем инструкции IN/OUT, попробовать их выполнить, произойдет исключение General Protection Fault (exception 0Dh, прерывание с вектором 0Dh=13). Дальнейшие действия зависят от того, как написана процедура обработки исключения: зависание, аварийное завершение, программная эмуляция порта и т. д.
Возможность прочитать из порта 80h значение, которое ранее было туда записано, была связана с наличием по этому адресу одного из незадействованных страничных регистров Legacy DMA (i8237). В ряде платформ блок страничных регистров Legacy DMA занимает 16 байт по адресам 80h-8Fh, несмотря на то, что DMA-каналов только 7 (8 если считать канал, используемый для каскадирования). Именно в силу наличия доступных для чтения DMA Page Registers порт 80h был читаемым, ведь сама POST-карта не поддерживает чтение порта, только запись. Legacy DMA не стало немного раньше, чем IN/OUT.
Очень жаль, что питание Racing P1 не предусматривает использования USB Type-C. Внешний адаптер слегка напрягает. Понятно, что и для автономного питания через USB-C понадобится аналогичный. Но здесь возможны сюрпризы.
Если сгенерирован Page Fault (PF, vector 0Eh), значит исследуемая последовательность байтов является инструкцией, при этом ее часть «залезла» на вторую страницу, что позволяет сделать вывод о длине байтового представления инструкции.
Если вместо Page Fault генерируется General Protection Fault (GPF, vector 0Dh) или Invalid Opcode Exception (vector 06h), то это значит, что байтов, расположенных в первой странице, процессору достаточно, чтобы «понять» что операция недопустима, «понять» до попытки адресации второй страницы.
Когда-то делали что-то подобное под DOS для поиска недокументированных MSR. Но там все было значительно проще:
Делая тот же трюк с недокументированными кодами инструкций нет уверенности в том, что на любой недопустимый код операции процессор дисциплинированно сгенерирует #UD (vector 06h) или #GPF (vector 0Dh), в ходе исследования возможны зависания и рестарты, вероятность которых можно уменьшить, проводя исследования на виртуальной машине, что автор и сделал.
Если строка перезаписана полностью (записано 64 байта по адресу кратному 64), то исходное содержимое ОЗУ можно проигнорировать, так как оно полностью «перекрыто» новыми данными и содержимое кэш-строки является функцией только данных записи и не является функцией исходного содержимого ОЗУ.
Такой метод обслуживания записи без обращения к ОЗУ, экономит не только такты, но и потребляемую мощность. Да, верно подмечено, у процессоров Intel, поддерживающих AVX512, инициировать 64-байтную запись можно и без CLZERO инструкцией записи, например, VMOVAPD [rax],zmm0. Такой подход работает для 64-байтных кэш-строк (512 бит = 64 байта), но пока нет оснований полагать, что размер кэш-строк изменится в новых процессорах. Или есть?
Спасибо PowerPC, кстати.