[...]
>> вычислительных задач (CPU-bound нежели I/O bound). Ну да, крякеры мд5 на
>> скорость тормзить не будут. А вот I/O bound программы (столь типичные
>> для серверов) будут часто стоять колом[...]
> Если не будет параллельной работы userland-кода, то весь супер-пупер-быстрый ввод-вывод
> будет всё равно упираться в не успевающую его прожёвывать программу.
Ввод-вывод не может ни во что упереться, а программа ничего не должна успевать за ядром. Вы путаете причинно-следственную связь: программа через сисколы просит ядро сделать вон то и вон это. А ядро идет и делает. Ядро не может сделать больше чем его попросили. Оно может протормозить с выполнением сискола, но больше чем программе надо - оно в принципе запихнуть в нее не может. Потому что это программа инициирует запрос, а ядро его разруливает.
> Единственное исключение - ситуации, когда ввод-вывод полностью или
> практически полностью обрабатывается ядром: та же маршрутизация сетевых
> пакетов, например (т.е. сквозь машину, а не к ней или от неё).
Что значит - единственное исключение? Юзерланд, особенно способный к работе на нескольких процессорах - на раз упрется в I/O (застряв в ядре). Ядро не может упереться в юзерланд потому что это юзерланд запросы инициирует. Ему нельзя впихнуть больше чем он просит.
> Почти все задачи практического применения - либо в первую очередь
> нагружают вычислительные мощности, либо нагружают всё подряд.
Да ладно вам, те же БД/веб/файлопомойки/роутилки/что там еще - обычно именно I/O bound при правильном подходе. Чисто числокрушильные машины... хм, прости, дядя, они на линуксе обычно. А под опенка вообще есть драйвера с поддержкой OpenCL/CUDA/что там еще, чтобы считать его платформой для крушения чисел? А то видеокарты рвут на этом поприще обычные процессоры на британский флаг просто. Почти все кого колыхали интенсивные вычисления уже используют GPU. Потому что по MIPS/Watt - непобедимо.
> Так что параллельная работа userland-кода всё-таки важнее: для десктопа, для
> web-сервера, для СУБД...
При правильном подходе они будут именно I/O bound. Если это не так - значит где-то ступили. Нет, я конечно понимаю что можно жить в мире тормозных апачей умирающих от 10 юзеров. Но нынче используется нжинкс, который статику вообще лупит как из пушки. В нем нечему проц грузить, собственно. И тормозные скриптобэкэнды имеет смысл жестоко кешировать, как раз чтобы процы разгрузить, ага :))
> Вот, скажем, почтовый релей или распределённая лёгковесная СУБД,
> например, уже может при определённых условиях упереться в ввод-вывод, да. Но
> и в них большая часть работы идёт в userland'е.
Да почти все кроме совсем уж числокрушилок типа кряка хешей и майнинга коинов и прочих формул белков и что там еще - может упереться в именно I/O. Чем ядро быстрее отстреляется, тем лучше: прога меньше висеть будет, ожидая возврата из сискола.
