Анонимный разработчик ядра Windows объясняет, почему винда медленнее других ОС
(Комментарий MrBison: я осознаю, что совсем недавно высказывал противоположные мнения, но не опубликовать это я просто не могу.)
Один из разработчиков ядра Windows, в обсуждении проблем с её производительностью на сайте Hacker News, высказался на тему причин, из-за которых эта самая производительность так сильно страдает. К сожалению, оригинальный пост потом был им же удалён, но его копия доступна по следующей ссылке: http://blog.zorinaq.com/?e=74
Одной из основных причин, почему производительность винды так сильно отстаёт от других ОС, анонимный разработчик назвал отсутствие интереса (и мотивации) в её улучшении. В Microsoft данную проблему не считают такой критичной, как другие.
Также он заметил, что попытки исправить проблемы винды зачастую не удаются потому, что разработчики отдельных компонентов противятся внедрению внешних патчей -- так как начальникам этих разработчиков эти патчи потом придётся поддерживать и оправдывать, тестерам -- смотреть, не сломалась ли совместимость, а проект-менеджеры не хотят заходить за расписания.
По отчётам этого разработчика, в Microsoft также отсутствует какая-либо мотивация разработчиков в плане инноваций. Если патч, увеличивающий производительность на 5%, в ядре линукса сделает разработчика известным в узких кругах, то в винде от этого преимущество куда меньше.
Новые разработчики, заменяющие уходящих в другие компании, зачастую не понимают, зачем были сделаны определённые решения, и, в результате этого, не хотят их совершенствовать -- вместо этого внедряя всё новые и новые подсистемы. (комментарий MrBison: я считаю это хорошей вещью, т.к. сохраняется обратная совместимость)
Комментарии
comrade
11 мая, 2013 - 16:25
Большинство виндовсов приобретается с новыми, более мощными, компьютерами. Покупаешь новый компьютер — с ним, в нагрузку, покупаешь новый виндовс.
Виндовс почти монополист, так что новые версии программ делают уже для новой версии виндовса.
Приходится парк компьютеров досрочно обновлять, и с каждого компа микрософту денежка капает.
А линукс на компьютере можно хоть 10 лет обновлять, без замены оборудования (по памяти только требования чуть выросли).
pomodor
11 мая, 2013 - 17:11
А я что говорил? ;)
А вообще, объяснение этого стукачка напомнили мне объяснения Василия Алибабаевича по поводу того, почему на его бензоколонке бензин не очень качественный. ;)
Чингачгук
11 мая, 2013 - 19:20
А я не считаю. Объясню почему.
Разработчиков прикладного уровня совершенно не интересует как конкретно реализованы определённые функции ядра. Им интересно только API. А реализовать его неизменно не такая уж и неподъёмная задача.
В качестве примера приведу ядро Linux в котором каждые два года вносятся какие-нибудь существенные изменения. Но API прикладного уровня остаётся неизменным уже лет 15.
Но в Linux разработчик вынужден описать почему он принял такое решение, а не альтернативное, которых всегда много, если не желает, чтобы его творение сгинуло на свалке истории. Естественно, никто не любит велосипедостроителей, поэтому, предлагая свой подход, программист FOSS должен доказать, что в данном случае лучше всё же сделать это новой технологией, а не дорабатывать старую.
В проприетарщине всё как раз наоборот. Судите сами, что звучит лучше в отчёте <<Мы улучшили нашу технологию X на 5%!>> или <<Мы применили совершенно новую, самую быструю технологию Y в замен устаревшей технологии X!>>.
Чингачгук
11 мая, 2013 - 20:28
> API прикладного уровня остаётся неизменным
прикладной уровень не взаимодействует с linux-ом вообще.
Чингачгук
13 мая, 2013 - 00:04
Я так понимаю, команда fork создаёт новый процесс путём магии розовых пони?
Для вашего сведения: в GNU/Linux любая команда прикладного уровня в конечном счёте делает вызов ядра, даже если эта функция реализована в BIOS или чём-то подобном.
Чингачгук
12 мая, 2013 - 13:20
Ага. То-то Поттеринг во всю бесчинствует и делает, что ему хочется.
MrBison
12 мая, 2013 - 13:51
К сожалению, придётся сказать, что лично я считаю разработки Поттеринга вполне адекватными. Их основная проблема скорее в том, что их слишком рано принимают в дистрибутивы, т.к. через некоторое время они уже становятся вполне юзабельными.
Комментировать