История изменений
Исправление
mv,
(текущая версия)
:
всё это в компиляторах часто сделано через жопу. а с учётом новых фич процессоров, новых команд - компиляторы вообще иногда не поспевают за развитием железа.
Думаю, кому-то надо освежить тему компиляторов. Новые фичи процов в компиляторах появляются задолго до появления этих процов на полках магазинов.
и да, про TCP/IP-стек. в ядре почему-то основная его тяжёлая часть, криптография, на ассемблере написана. разработчики не знали, что у вас пацталом процы простаивают. и написали зачем-то криптографию на ассемблере.
Пример основной тяжёлой части в TCP/IP-стеке, недавно пофикшенной: IO-path в драйвере сетевухи и IP-стеке не вмешался в L1i. Чувак добавил чутка кода, худо-бедно классифицирующего пакеты, собирающий их в списки и спускающего этот список в IP-стек. L1i вдруг стал горячим, IO полетели бодрее.
и написали зачем-то криптографию на ассемблере. и, главное, даже ассемблерные куски оптимизируют периодически. всякие там конвейерные операции втаскивают.
Да, и при запуске на конкретной машине быстренько прогоняют тесты, какая из реализаций лучше, ту и используют. Авторам этих ассемблерных портянок заранее знать, какая хрень лучше именно на этом процессоре работает, невозможно.
Или вот какая замечательная портянка: https://elixir.bootlin.com/linux/latest/source/arch/x86/lib/copy_user_64.S Знал ли автор, что на Netburst она работает хорошо, на Core значительно хуже, а примерно так с Nehalem вообще хуже банального rep movsb, который даже самый стрёмный gcc сгенерирует?
Исходная версия
mv,
:
всё это в компиляторах часто сделано через жопу. а с учётом новых фич процессоров, новых команд - компиляторы вообще иногда не поспевают за развитием железа.
Думаю, кому-то надо освежить тему компиляторов. Новые фичи процов в компиляторах появляются задолго до появления этих процов на полках магазинов.
и да, про TCP/IP-стек. в ядре почему-то основная его тяжёлая часть, криптография, на ассемблере написана. разработчики не знали, что у вас пацталом процы простаивают. и написали зачем-то криптографию на ассемблере.
Пример основной тяжёлой части в TCP/IP-стеке, недавно пофикшенной: IO-path в драйвере сетевухи и IP-стеке не вмешался в L1i. Чувак добавил чутка кода, худо-бедно классифицирующего пакеты, собирающий их в списки и спускающего этот список в IP-стек. L1i вдруг стал горячим, IO полетели бодрее.
и написали зачем-то криптографию на ассемблере. и, главное, даже ассемблерные куски оптимизируют периодически. всякие там конвейерные операции втаскивают.
Да, и при запуске на конкретной машине быстренько прогоняют тесты, какая из реализаций лучше, ту и используют. Авторам этих ассемблерных портянок заранее знать, какая хрень именно на этом процессоре работает, невозможно.
Или вот какая замечательная портянка: https://elixir.bootlin.com/linux/latest/source/arch/x86/lib/copy_user_64.S Знал ли автор, что на Netburst она работает хорошо, на Core значительно хуже, а примерно так с Nehalem вообще хуже банального rep movsb, который даже самый стрёмный gcc сгенерирует?