Разработчик ядра Windows NT объяснил причины низкой производительности

[gnuuser]

Один из программистов компании Microsoft анонимно выступил на форуме Hacker News и выдал интересные подробности о процессе разработки ядра NT. Своим сообщением он хотел подтвердить тезис о том, что ядро неэффективно и во многом уступает по производительности другим ОС: см. оригинальное сообщение (автор удалил его, испугавшись резких формулировок) и копию.
Причина проблем, по словам сотрудника Microsoft, социальная. Дело в том, что разработчики не вносят в ядро таких оптимизаций, которые мы видим в мире Linux. В компании Microsoft никто не будет хвалить программиста, если он оптимизировал какой-то процесс на 5%, если это не входит в сферу его основных обязанностей. Такая оптимизация никому не интересна. Только в случае какого-то очень существенного прогресса работу программиста могут заметить в соседних командах разработки, что положительно отразиться на его карьере. Но это скорее исключение, чем правило. Нет никакого стимула принимать изменения из-за пределов своей команды разработки.

В Microsoft не существует программы по систематическому улучшению производительности Windows. Во времена Windows XP компания начала уделять большое внимание безопасности, потому что с этим обнаружились серьёзные проблемы. Однако на производительность никто не обращал и не обращает особого внимание.

Ещё одна проблема в ухудшении ситуации с производительностью ОС — в утечке самых талантливых кадров. Google и другие компании Кремниевой долины активно охотятся за одаренными программистами и не стесняются переманивать их из других компаний. Из-за текучки кадров новые разработчики предпочитают реализовывать новые функции вместо оптимизации старых. Именно в этом причина появления PowerShell: многие хотели улучшить cmd.exe, но не имели возможности.

В качестве конкретных примеров разработчик называет следующее:

«Нам нельзя трогать именованные каналы. Лучше добавим %INTERNAL_NOTIFICATION_SYSTEM%! И пусть она будет несовместима с почти всеми другими именованными примитивами NT.

Мы не можем показывать %INTERNAL_NOTIFICATION_SYSTEM% остальному миру, потому что не хотим заниматься бумажной работой и терять продажи, ведь сейчас публично доступны только интерфейса Win32 APIs эпохи 90-х.

Мы не можем трогать DCOM. Так что создадим ещё один %C#_REMOTING_FLAVOR_OF_THE_WEEK%!

XNA. Что тут ещё сказать?

Зачем кому-то нужен формат архивирования с поддержкой файлов больше 2 ГБ?

Давайте поддерживать символьные ссылки, но убедимся, что никто не сможет их использовать, так что нас не обвинят в уязвимости безопасности. (Отлично! Теперь мы выглядим мудрыми и ответственными!)

Нельзя трогать Source Depot, так что давайте вместе хакнем SDX (Secure Document Exchange)!

Нельзя трогать SDX, так что давайте притворяться в течение четырёх релизов, что мы переходим на TFS (Team Foundation Server), а сами ничего не будем менять!

Господи, код NTFS — это багровый роман ужасов, написанный под опиумом в средневековье, где используются глобальные рекурсивные блокировки и управление потоком выполнения программы при помощи структурной обработкой исключений (SEH). Давайте вместо неё напишем ReFs. (И да, начнем с копипаста исходников NTFS и удаления половины функциональности! Теперь добавим контрольные суммы, потому что контрольные суммы это круто, и с контрольными суммами мы почти так же круты, как ZFS, верно? И вообще, кому нужны квоты?)

Мы вообще не в силах реализовать поддержку C11, а шаблоны с переменным числом аргументов слишком сложны, чтобы внедрить их за год. (Но смотрите, мы превратили "^" в оператор указателя с подсчётом ссылок! Ой, а что такое ссылочный цикл?)».

PS В оригинале статья интереснее. Разработчик дописал ее. ...This anonymous poster contacted me, still anonymously, to make a second statement, worried by the attention his words are getting... Автор написал, что Windows сейчас пишут вчерашние студенты. Хотя ... Windows and Microsoft still have plenty of technical talent. И т.д

http://linexp.ru/other/razrabotchik-...itelnosti.html