Прежде чем переходить к обсуждению утверждения "ядро тормозное", отмечу две вещи по исходному утверждению "возможность разработки на C увеличит скорость работы". Во-первых, даже если считать, что ядро действительно тормозное, первое утверждение отсюда совершенно не следует. Во-вторых, если заниматься не философствованиями, а конкретными измерениями, то ассемблер заметно выигрывает у си:
http://wasm.ru/forum/viewtopic.php?pid=276576#p276576
wolf.ram wrote:Гы-ы-ы. Забавно, что утверждение о каком-то разрушении буфера может серьёзно просадить скорость тормозного до невозможности ядра.
Вряд ли кто-то может сказать, что при написании кода рассчитывал распределение регистров и команд по конвейерам.
Утверждение, разумеется, просадить ничего не может. Но это так, к слову.
Интересно отметить, что характерные отзывы о Колибри как раз наоборот подчёркивают скорость работы системы. По контексту высказывания складывается ощущение, что высказывание вызвано исключительно теоретическими соображениями типа "для оптимального кода нужно рассчитывать распределение регистров и команд по конвейерам". Поэтому небольшой ликбез. Регистры по конвейерам никто не распределяет, распределяют переменные по регистрам, и это как раз ассемблерщик делает и сам - выделить часто используемые переменные и выделить под эти часто используемые переменные конкретные регистры несложно и интуитивно делается, чтобы избежать писания лишних mov'ов. Распределение команд по конвейерам появилось, когда в процессорах появился сам конвейер, и даже тогда было средством оптимизации из разряда "ловли блох", когда все остальные оптимизации уже проведены, а это может ещё пару-тройку тактов сэкономить. С тех пор процессоры ещё поумнели и могут переупорядочивать команды (а точнее, микрооперации, на которые эти команды разбиваются) самостоятельно и выполнять их в том порядке, как им удобно. Более того, у разных процессоров разная микроархитектура, разные возможности конвейеров, так что "шедулинга инструкций", оптимального для всех процессоров, просто не может существовать.
wolf.ram wrote:Зато умиляют пары инструкций типа
Код:
xor [reg], [reg]
inc/dec/not [reg]
в коде загрузки. Который выполняется 1 раз. К тому же колибря долгое время умела грузиться только с дискеты. И такой код «оптимизации» на фоне чтения с флопика выглядит мощно.
Вот вычитал кульхацкер в какой-то древней книжке по асму, что inc выполняется быстрее, чем add, и пошёл впиливать где можно.
А на процах до PIV, на ядре prescott, помоему, add-таки выполнялся быстрее…
Факты Вы видите, а вот выводы из них почему-то не делаете. Вы же правильно заметили, что код загрузки выполняется один раз. И правильно заметили, что на фоне чтения с флопика скорость особого значения не имеет. Только отсюда Вы почему-то делаете вывод, что эти инструкции вставил кульхацкер, и приписываете ему стремление увеличить скорость, для чего Вам приходится вводить допущение, что "в какой-то древней книжке по асму" написано, "что inc выполняется быстрее, чем add". Команда inc не может выполняться быстрее, чем add (хотя, как Вы правильно заметили, на некоторых процессорах бывает медленнее), и никогда не выполнялась быстрее. Более того, очевидно, что вместо xor eax,eax/inc eax вполне можно написать mov eax,1, что будет заведомо быстрее и даже потребует меньше нажатий на клавиши для набора. Ну так сделайте из всего этого логический вывод! Даю подсказку: машинный код пары команд xor eax,eax/inc eax в 32-битном режиме есть 33 C0 40 (или, что эквивалентно, 31 C0 40), машинный код команды mov eax,1 есть B8 01 00 00 00.
wolf.ram wrote:Вместо того, чтоб повыкинуть кучу статических массивов, которые вносят всякие нелепые ограничения на ресурсы, вроде количества процессов.
Не возражаю против утверждения, что в ядре присутствует куча статических массивов, не возражаю против того, что этого можно было бы избежать и даже следовало бы избежать. Но должен отметить две вещи: во-первых, использование статических массивов вместо динамических списков ускоряет ядро (за счёт меньшего числа разыменований указателей для доступа к элементам), а не замедляет; во-вторых, это вообще никак не связано со сравнением ассемблера и си.