LINUX.ORG.RU

История изменений

Исправление 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 сгенерирует?