Один из программистов компании 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, а шаблоны с переменным числом аргументов слишком сложны, чтобы внедрить их за год. (Но смотрите, мы превратили «^» в оператор указателя с подсчитанными ссылок! Ой, а что такое подсчёт ссылок?)».
←
1
2
→

Ответ на:
комментарий
от Programmist11180


Ответ на:
комментарий
от en

Ответ на:
комментарий
от Reset


Ответ на:
комментарий
от ritsufag




Ответ на:
комментарий
от TGZ


Ответ на:
комментарий
от Begemoth


Ответ на:
комментарий
от RedPossum

Ответ на:
комментарий
от rezedent12

Ответ на:
комментарий
от Nebuchadnezzar

Ответ на:
комментарий
от Sadler

Ответ на:
комментарий
от rezedent12

Ответ на:
комментарий
от Reset

Ответ на:
комментарий
от RedPossum

Ответ на:
комментарий
от TGZ

Ответ на:
комментарий
от Reset

Ответ на:
комментарий
от LongLiveUbuntu

Ответ на:
комментарий
от onanij

Ответ на:
комментарий
от Begemoth


Ответ на:
комментарий
от TGZ

Ответ на:
комментарий
от Begemoth

Ответ на:
комментарий
от Begemoth


Ответ на:
комментарий
от Programmist11180



Ответ на:
комментарий
от Reset

Ответ на:
комментарий
от rezedent12

Ответ на:
комментарий
от gh0stwizard

Ответ на:
комментарий
от TGZ



Ответ на:
комментарий
от ritsufag

Ответ на:
комментарий
от drull

Ответ на:
комментарий
от Dark_SavanT

Ответ на:
комментарий
от drull

Ответ на:
комментарий
от Nebuchadnezzar


Ответ на:
комментарий
от ya-betmen

Ответ на:
комментарий
от gh0stwizard

Ответ на:
комментарий
от Mitre

Ответ на:
комментарий
от x0r

Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Похожие темы
- Форум Низкая производительность (2016)
- Форум Низкая производительность LinuxZFS (2016)
- Форум GlusterFS. Низкая производительность. (2017)
- Форум Низкая производительность RAID1 (2015)
- Форум Низкая производительность видео (2015)
- Форум Низкая производительность видеокарты (2011)
- Форум SSD низкая производительность (2019)
- Форум Низкая производительность OpenGL (2013)
- Форум Низкая производительность дискретки (2014)
- Форум Низкая производительность optirun (2018)