Mac 152

шал, что создание нового процесса на Windows-коробке дороже, чем на Linux. Это правда? Может кто-нибудь объяснить технические причины, почему это дороже, и предоставить какие-либо исторические причины для проектных решений, стоящих за этими причинами?

Ответы на вопрос(10)

в настоящее время у вас есть такие вещи, как Native POSIX Thread Library - если хотите. Но долгое время единственным способом «делегировать» работу в мире Unix было использование fork () (и это все еще предпочитается во многих, многих обстоятельствах). например какой-то сокет сервер

socket_accept()
fork()
if (child)
    handleRequest()
else
    goOnBeingParent()
Поэтому реализация fork должна быть быстрой, и с течением времени было реализовано много оптимизаций. Microsoft одобрила CreateThread или даже волокна вместо создания новых процессов и использования межпроцессного взаимодействия. Я думаю, что не совсем справедливо сравнивать CreateProcess с fork, поскольку они не являются взаимозаменяемыми. Вероятно, более уместно сравнить fork / exec с CreateProcess.

 ctrl-alt-delor22 нояб. 2018 г., 12:12
Но fork + exec в Linux работает быстрее, чем CreateThread в MS-Windows. А Linux может делать форк самостоятельно, чтобы быть еще быстрее. Однако вы сравниваете это, MS медленнее.
 acib70824 июл. 2015 г., 00:07
Ах, глагол для пчелы.
 Blaisorblade12 янв. 2009 г., 05:04
О вашем последнем замечании: fork () не подлежит обмену с CreateProcess (), но можно также сказать, что Windows должна реализовать fork (), потому что это дает большую гибкость.

NT был спроектирован для многопользовательской работы с первого дня, так что на самом деле это не причина. Однако вы правы в том, что создание процессов играет в NT меньшую роль, чем в Unix, поскольку NT, в отличие от Unix, предпочитает многопоточность, а не многопроцессорность.

Роб, это правда, что форк относительно дешев, когда используется COW, но на самом деле за форком в большинстве случаев следует exec. И исполнительный директор должен также загрузить все изображения. Обсуждение производительности форка, следовательно, является лишь частью правды.

При обсуждении скорости создания процесса, вероятно, будет хорошей идеей провести различие между NT и Windows / Win32. Что касается NT (то есть самого ядра), я не думаю, что создание процессов (NtCreateProcess) и создание потоков (NtCreateThread) значительно медленнее, чем в среднем в Unix. Возможно, будет происходить немного больше, но я не вижу основной причины разницы в производительности здесь.

Однако, если вы посмотрите на Win32, вы заметите, что он добавляет много накладных расходов на создание процесса. Во-первых, он требует, чтобы CSRSS был уведомлен о создании процесса, который включает в себя LPC. Для этого требуется как минимум ядро ​​32 для дополнительной загрузки, и он должен выполнить ряд дополнительных рабочих операций бухгалтерии, прежде чем процесс будет считаться полноценным процессом Win32. И давайте не будем забывать обо всех дополнительных накладных расходах, возникающих при разборе манифестов, проверке, требует ли образ прокладку совместимости, проверке, применяются ли политики ограниченного использования программ, yada yada.

Тем не менее, я вижу общее замедление в сумме всех тех мелочей, которые нужно сделать в дополнение к необработанному созданию процесса, пространства виртуальных машин и исходного потока. Но, как было сказано в начале - из-за предпочтения многопоточности по сравнению с многозадачностью, единственное программное обеспечение, которое серьезно затронуто этими дополнительными затратами, - это плохо портированное программное обеспечение Unix. Хотя эта ситуация меняется, когда такие программы, как Chrome и IE8, неожиданно открывают преимущества многопроцессорной обработки и начинают часто запускать и завершать процессы ...

 Blaisorblade12 янв. 2009 г., 05:02
За Fork не всегда следует exec (), и люди заботятся только о fork (). Apache 1.3 использует fork () (без exec) в Linux и потоки в Windows, даже если во многих случаях процессы разветвляются до того, как они нужны, и хранятся в пуле.
 Miles Rout05 февр. 2017 г., 22:08
-1. Утверждение, что программное обеспечение «плохо портировано», потому что оно плохо работает в плохо спроектированной операционной системе, полной несовместимости, которая замедляет процесс создания, просто смешно.
 Chris Huang-Leaver03 авг. 2009 г., 15:07
Не забывая, конечно, команду 'vfork', которая разработана для сценария 'just call exec', который вы описываете.
 Dizzyspiral17 февр. 2017 г., 16:03
@MilesRout целью портирования является модификация программного обеспечения для работы в новой целевой системе с учетом сильных и слабых сторон этой системы. Плохо работающее портированное программное обеспечениеявляется плохо перенесенное программное обеспечение, независимо от препятствий, которые предоставляет операционная система.
 Dan Moulding11 авг. 2016 г., 17:51
Другой вид программного обеспечения, котороешутки в сторону На это влияет любой вид сценариев оболочки, который включает в себя координацию нескольких процессов. Например, скрипты Bash внутри Cygwin сильно страдают от этого. Рассмотрим цикл оболочки, который порождает много sed, awk и grep в конвейерах. Каждая команда порождает процесс, а каждая труба порождает подоболочку и новый процесс в этой подоболочке. Unix был разработан с учетом этого вида использования, поэтому быстрое создание процессов остается нормой там.
Краткий ответ - «программные слои и компоненты».

нтов, которых нет в Unix или которые упрощены и обрабатываются внутри ядра в Unix.

В Unix fork и exec являются прямыми вызовами ядра.

В Windows API ядра не используется напрямую, поверх него есть win32 и некоторые другие компоненты, поэтому создание процесса должно проходить через дополнительные слои, а затем новый процесс должен запускаться или подключаться к этим слоям и компонентам.

В течение достаточно долгого времени исследователи и корпорации пытались смутно подобрать Unix, обычно основывая свои эксперименты наЯдро маха; хорошо известный примерOS X., Однако каждый раз, когда они пытаются это сделать, они становятся настолько медленными, что в конечном итоге они, по крайней мере, частично объединяют части обратно в ядро ​​либо навсегда, либо для производственных поставок.

 ctrl-alt-delor18 июл. 2018 г., 09:42
Слои не обязательно замедляют работу: я написал драйвер устройства с множеством слоев на языке C. Чистый код, грамотное программирование, легкость чтения. Это было быстрее (незначительно), чем версия, написанная на высоко оптимизированном ассемблере, без слоев.
 ctrl-alt-delor10 янв. 2019 г., 11:49
Ирония в том, что NT - это огромное ядро ​​(а не микроядро)

по-видимому, есть какое-то оправдание MS-Windows, например,

«Ядро NT и Win32 - это не одно и то же. Если вы программируете на ядро ​​NT, это не так уж и плохо »- правда, но если вы не пишете подсистему Posix, то кого это волнует? Вы будете писать в win32.«Несправедливо сравнивать форк, с ProcessCreate, поскольку они делают разные вещи, а в Windows нет форка» - правда, поэтому я буду сравнивать подобное с лайком. Однако я также буду сравнивать fork, потому что он имеет много вариантов использования, таких как изоляция процесса (например, каждая вкладка веб-браузера работает в отдельном процессе).Теперь давайте посмотрим на факты, в чем разница в производительности?

Данные зарезервированы отhttp://www.bitsnbites.eu/benchmarking-os-primitives/.
Поскольку смещение неизбежно, при обобщении я сделал это в пользу MS-Windows
Аппаратное обеспечение для большинства тестов i7 8 core 3,2 ГГц. За исключением Raspberry-Pi под управлением Gnu / Linux

В порядке скорости, от самой быстрой до самой медленной (числа - время, меньше - лучше).

Linux CreateThread 12Mac CreateThread 15Linux Fork 19Windows CreateThread 25Linux CreateProcess (форк + exec) 45Mac Fork 105Mac CreateProcess (форк + exec) 453Raspberry-Pi CreateProcess (форк + exec) 501Windows CreateProcess 787Windows CreateProcess с антивирусным сканером 2850Windows Fork (симуляция с помощью CreateProcess + fixup) больше 2850

Примечания: на Linuxfork быстрее, чем MS-Windows предпочитал метод CreateThread.

Теперь о некоторых других фигурахСоздание файла.Linux 13Mac 113Windows 225Raspberry-Pi (с медленной SD-картой) 241Windows с защитником, антивирусом и т. Д. 12950Выделение памятиLinux 79Windows 93Mac 152

Я думаю, что люди могли бы извлечь выгоду из чтения "Showstopper"; книга о разработке Windows NT.

Единственная причина, по которой службы выполнялись как библиотеки DLL в одном процессе в Windows NT, заключалась в том, что они были слишком медленными, как отдельные процессы.

Если вы не справитесь, вы обнаружите, что проблема заключается в стратегии загрузки библиотеки.

На Unices (в общем) сегменты кода общих библиотек (DLL) фактически являются общими.

Windows NT загружает копию библиотеки DLL для каждого процесса, поскольку после загрузки она манипулирует сегментом кода библиотеки (и сегментом исполняемого кода). (Сообщает, где ваши данные?)

Это приводит к сегментам кода в библиотеках, которые нельзя использовать повторно.

Таким образом, процесс создания NT на самом деле довольно дорогой. С другой стороны, это делает DLL не заметной экономией в памяти, а шансом проблем с зависимостями между приложениями.

Иногда в инженерном деле стоит отступить назад и сказать: «Теперь, если бы мы собирались спроектировать это так, чтобы он действительно отстой, как бы это выглядело?»

Я работал со встроенной системой, которая когда-то была довольно темпераментной, и однажды посмотрел на нее и понял, что это полостной магнетрон с электроникой в ​​микроволновой полости. После этого мы сделали его намного более стабильным (и менее похожим на микроволновую печь).

 Mike Dimmick17 сент. 2008 г., 14:47
Сегменты кода могут использоваться повторно до тех пор, пока DLL загружается по своему предпочтительному базовому адресу. Традиционно вы должны убедиться, что вы установили не конфликтующие базовые адреса для всех библиотек DLL, которые будут загружаться в ваши процессы, но это не работает с ASLR.
 Johannes Passing04 дек. 2009 г., 20:31
Совместное использование разделов кода работает и в системах с поддержкой ASLR.
 Zan Lynx21 окт. 2008 г., 02:11
Есть какой-то инструмент, чтобы перебазировать все DLL, не так ли? Не уверен, что он делает с ASLR.
 ctrl-alt-delor10 янв. 2019 г., 11:46
@MikeDimmick, поэтому все, кто создает DLL, должны сотрудничать, чтобы гарантировать отсутствие конфликтов, или вы исправляете их все на системном уровне перед загрузкой?

что ключом к этому является историческое использование обеих систем. Windows (и DOS до этого) изначально были однопользовательскими системами дляличный компьютеры. Таким образом, эти системы обычно не должны создавать много процессов постоянно; (очень) проще говоря, процесс создается только тогда, когда этот одинокий пользователь запрашивает его (и мы, люди, работаем не очень быстро, условно говоря).

Unix-системы изначально были многопользовательскими системами и серверами. Особенно для последних весьма часто иметь процессы (например, mail или http-демоны), которые разделяют процессы для обработки определенных заданий (например, заботятся об одном входящем соединении). Важным фактором в этом является дешевыйfork метод (который, как упоминал Роб Уокер (47865), изначально использует ту же память для вновь созданного процесса), что очень полезно, поскольку новый процесс сразу же получает всю необходимую ему информацию.

Ясно, что, по крайней мере, исторически потребность в быстрых процессах создания систем на основе Unix намного выше, чем в системах Windows. , что это все еще так, потому что Unix-системы по-прежнему очень ориентированы на процессы, в то время как Windows из-за своей истории, вероятно, была более ориентированной на потоки (потоки полезны для создания адаптивных приложений).

Отказ от ответственности: я ни в коем случае не эксперт в этом вопросе, так что прости меня, если я ошибся.

что модель безопасности в Windows значительно сложнее, чем в Unix-системах, что добавляет много накладных расходов при создании процессов. Еще одна причина, по которой многопоточность предпочтительнее многопроцессорности в Windows.

 Woodrow Douglass30 дек. 2011 г., 16:00
@LieRyan, В разработке программного обеспечения (по моему опыту) более сложное очень редко означает более безопасный.
 Spudd8602 авг. 2011 г., 20:48
SELinux также очень сложная модель безопасности, и она не накладывает значительных накладных расходов наfork()
 Lie Ryan25 мая 2011 г., 17:05
Я ожидаю, что более сложная модель безопасности будет более безопасной; но факты показывают иначе.

что на машине Win, скорее всего, антивирусное программное обеспечение сработает во время CreateProcess ... Это обычно самое большое замедление.

большая часть накладных расходов принадлежит запуску Win32 для процесса.

Ядро Windows NT на самом деле поддерживает форк COW.СФУ (Среда Microsoft UNIX для Windows) использует их. Тем не менее, Win32 не поддерживает форк. Процессы SFU не являются процессами Win32. SFU ортогонален Win32: они обе подсистемы среды, построенные на одном ядре.

В дополнение к внепроцессным вызовам LPCCSRSS, в XP и более поздних версиях существует внепроцессный вызов механизма совместимости приложений, чтобы найти программу в базе данных совместимости приложений. Этот шаг вызывает достаточные накладные расходы, что Microsoft предоставляет возможность групповой политики дляотключить движок совместимости на WS2003 по причинам производительности.

Библиотеки времени выполнения Win32 (kernel32.dll и т. Д.) Также выполняют много операций чтения и инициализации реестра при запуске, которые не применяются к UNIX, SFU или собственным процессам.

Собственные процессы (без подсистемы среды) создаются очень быстро. SFU делает намного меньше, чем Win32 для создания процессов, поэтому его процессы также быстро создаются.

ОБНОВЛЕНИЕ ДЛЯ 2019: добавьте LXSS:Подсистема Windows для Linux

Замена SFU для Windows 10 - это подсистема среды LXSS. Это 100% режим ядра и не требует никакого IPC, который Win32 продолжает использовать. Системный вызов для этих процессов направляется непосредственно в lxss.sys / lxcore.sys, поэтому вызов fork () или другого процесса, создающего вызов, стоит всего 1 системного вызова для создателя, всего.[Область данных, называемая экземпляром] отслеживает все процессы LX, потоки и состояние времени выполнения.

Процессы LXSS основаны на собственных процессах, а не на процессах Win32. Все специфичные для Win32 вещи, такие как механизм совместимости, вообще не задействованы.

fork', который 'разделяет' текущий процесс на два и дает вам второй процесс, идентичный первому (по модулю возврата из вызова fork). Поскольку адресное пространство нового процесса уже запущено и работает, это должно быть дешевле, чем вызывать «CreateProcess» в Windows и загружать образ exe, связанные библиотеки и т. Д.

В случае ветвления ОС может использовать семантику «копирование при записи» для страниц памяти, связанных с обоими новыми процессами, чтобы гарантировать, что каждый получит свою собственную копию страниц, которые они впоследствии изменят.

 ctrl-alt-delor18 июл. 2018 г., 09:49
Я добавил некоторые данные о производительности в своем ответе.stackoverflow.com/a/51396188/537980 Вы можете видеть, что это быстрее.
 Joel Spolsky♦17 сент. 2008 г., 04:43
Этот аргумент верен только тогда, когда вы действительно разветвляетесь. Если вы начинаете новый процесс, в Unix вам все равно придется форк и exec. И Windows, и Unix имеют копию при записи. Windows, безусловно, будет повторно использовать загруженный EXE, если вы запустите вторую копию приложения. Я не думаю, что ваше объяснение правильное, извините.
 webkul09 нояб. 2009 г., 07:50
Подробнее о exec () и fork ()vipinkrsahu.blogspot.com/search/label/system%20programming

Ваш ответ на вопрос