> Ну фиг знает, что у вас то по производительности, но подход и
> правда хитрый. Другой вопрос, что много ли у вас в стандартном
> коде ОСи задействован fpu? (и тогда вопрос - на кой?) Поправил пост. Там не только FPU, но и SSE и AVX тоже общие! И целочисленный MMX. Все общее, кроме базового целочисленного модуля - хоть этот они поставили свой на каждое ядро. Если бы не сделали даже этого, оставались только бы раздельные регистры и это бы назвалось HT или SMT :) Но AMD называла это полноценными "ядрами".
А что касается "много ли где используются инструкции"... Тут ситуация такая, что обычно там, где не используются ни FPU, ни SSE, ни MMX, ни AVX производительность обычно-то и не нужна. Но замечу что даже memcpy() в glibc давно уже переписан на AVX, а при его отсутствии будет стараться брать SSE-версию. Даже куски памяти перемещать намного эффективнее блоками по 256 бит (или хотя бы по 128), чем по 64. Ну и вся криптография и распространенные хэш-функции (в т.ч. даже такие базовые вещи, как CRC32 - нужен, между прочим, очень много где даже в ядре) быстрее с этими инструкциями. Про мультимедию даже не заикаюсь.
На голом ALU быстро работать будут разве что вещи типа раздачи веб-контента. И то, memcpy/memmove/memset на AVX или SSE не помешают даже им. Вот эти функции https://github.molgen.mpg.de/git-mirror/glibc/tree/master/sy... с использованием SIMD в 2-3 раза быстрее, чем на ALU..
Кстати, по последним новостям (долго, однако, такие дела в суде идут, 4 года прошло) это дело таки признают, т.к. возражения AMD отвергли, и им придется серьезно заплатить за свои фейковые ядра: https://www.theregister.co.uk/2019/01/22/judge_green_lights_.../
