Ho sentito che creare un nuovo processo su una macchina Windows è più costoso che su Linux. È vero? Qualcuno può spiegare le ragioni tecniche per cui è più costoso e fornire eventuali ragioni storiche per le decisioni di progettazione alla base di tali ragioni?

mweerden: NT è stato progettato per il multiutente sin dal primo giorno, quindi non è proprio un motivo. Tuttavia, hai ragione sul fatto che la creazione di processi gioca un ruolo meno importante su NT che su Unix poiché NT, a differenza di Unix, preferisce il multithreading al multiprocessing.

Rob, è vero che fork è relativamente economico quando viene usato COW, ma in realtà fork è per lo più seguito da un exec. E anche un dirigente deve caricare tutte le immagini. Discutere le prestazioni del fork quindi è solo una parte della verità.

Quando si discute della velocità di creazione del processo, è probabilmente una buona idea distinguere tra NT e Windows / Win32. Per quanto riguarda NT (cioè il kernel stesso), non credo che la creazione di processi (NtCreateProcess) e la creazione di thread (NtCreateThread) siano significativamente più lente rispetto a Unix medio. Potrebbe succedere un po 'di più, ma qui non vedo il motivo principale della differenza di prestazioni.

Se guardi Win32, tuttavia, noterai che aggiunge un bel po 'di overhead alla creazione del processo. Per uno, richiede che il CSRSS riceva una notifica sulla creazione del processo, che coinvolge LPC. Richiede almeno il caricamento aggiuntivo di kernel32 e deve eseguire una serie di elementi di lavoro di contabilità aggiuntivi da eseguire prima che il processo sia considerato un processo Win32 a tutti gli effetti. E non dimentichiamoci di tutto il sovraccarico aggiuntivo imposto dall'analisi dei manifesti, controllando se l'immagine richiede uno shim di compatibilità, controllando se le politiche di restrizione del software si applicano, yada yada.

Detto questo, vedo il rallentamento generale nella somma di tutte quelle piccole cose che devono essere fatte oltre alla creazione grezza di un processo, spazio VA e thread iniziale. Ma come detto all'inizio, a causa del vantaggio del multithreading rispetto al multitasking, l'unico software che risente seriamente di questa spesa aggiuntiva è il software Unix con porting scadente. Sebbene questa situazione cambi quando software come Chrome e IE8 riscoprono improvvisamente i vantaggi del multiprocessing e iniziano ad avviare e smontare frequentemente processi ...

Unix ha una chiamata di sistema "fork" che "divide" il processo corrente in due e fornisce un secondo processo identico al primo (modulo il ritorno dalla chiamata fork). Poiché lo spazio degli indirizzi del nuovo processo è già attivo e in esecuzione, dovrebbe essere più economico che chiamare "CreateProcess" in Windows e caricare l'immagine exe, le DLL associate, ecc.

Nel caso del fork, il sistema operativo può utilizzare la semantica "copia su scrittura" per le pagine di memoria associate a entrambi i nuovi processi per garantire che ciascuno riceva la propria copia delle pagine che successivamente modificano.

In aggiunta a ciò che ha detto JP: la maggior parte del sovraccarico appartiene all'avvio di Win32 per il processo.

Il kernel di Windows NT supporta effettivamente il fork COW. SFU (ambiente UNIX di Microsoft per Windows) li utilizza. Tuttavia, Win32 non supporta il fork. I processi SFU non sono processi Win32. SFU è ortogonale a Win32: sono entrambi sottosistemi di ambiente costruiti sullo stesso kernel.

Oltre alle chiamate LPC out-of-process CSRSS, in XP e versioni successive è presente una chiamata out of process al motore di compatibilità dell'applicazione per trovare il programma nel database di compatibilità dell'applicazione. Questo passaggio causa un sovraccarico sufficiente che Microsoft fornisce un'opzione di criteri di gruppo per disabilitare il motore di compatibilità su WS2003 per motivi di prestazioni.

Le librerie di runtime Win32 (kernel32.dll, ecc.) Eseguono anche molte letture del registro e inizializzazioni all'avvio che non si applicano a UNIX, SFU o processi nativi.

I processi nativi (senza sottosistema di ambiente) sono molto veloci da creare. SFU fa molto meno di Win32 per la creazione dei processi, quindi anche i suoi processi sono veloci da creare.

AGGIORNAMENTO PER IL 2019: aggiungi LXSS: sottosistema Windows per Linux

La sostituzione di SFU per Windows 10 è il sottosistema dell'ambiente LXSS. È in modalità kernel al 100% e non richiede nessuno degli IPC che Win32 continua ad avere. Syscall per questi processi è diretto direttamente a lxss.sys / lxcore.sys, quindi fork () o un altro processo che crea una chiamata costa solo 1 chiamata di sistema per il creatore, in totale. [Un'area dati chiamata istanza] tiene traccia di tutti i processi, thread e stato di runtime LX.

I processi LXSS si basano su processi nativi, non su processi Win32. Tutte le cose specifiche di Win32 come il motore di compatibilità non sono affatto coinvolte.

Oltre alla risposta di Rob Walker: Al giorno d'oggi hai cose come la Native POSIX Thread Library, se vuoi. Ma per molto tempo l'unico modo per "delegare" il lavoro nel mondo unix è stato usare fork () (ed è ancora preferito in molte, molte circostanze). ad esempio una specie di server socket

socket_accept ()
forchetta()
se (bambino)
    handleRequest ()
altro
    goOnBeingParent ()

La chiave di questa questione è l'uso storico di entrambi i sistemi, credo. Windows (e DOS prima ancora) erano originariamente sistemi monoutente per personal computer. In quanto tali, questi sistemi in genere non devono creare molti processi tutto il tempo; In poche parole, un processo viene creato solo quando questo utente solitario lo richiede (e noi umani non operiamo molto velocemente, relativamente parlando).

I sistemi basati su Unix erano originariamente sistemi e server multiutente. Soprattutto per questi ultimi non è raro avere processi (es. Posta o demoni http) che suddividono processi per gestire lavori specifici (es. Prendersi cura di una connessione in entrata). Un fattore importante per fare ciò è il forkmetodo economico (che, come menzionato da Rob Walker ( 47865 ), utilizza inizialmente la stessa memoria per il processo appena creato) che è molto utile in quanto il nuovo processo ha immediatamente tutte le informazioni di cui ha bisogno.

È chiaro che, almeno storicamente, la necessità per i sistemi basati su Unix di avere una creazione rapida dei processi è molto maggiore rispetto ai sistemi Windows. Penso che sia ancora così perché i sistemi basati su Unix sono ancora molto orientati ai processi, mentre Windows, a causa della sua storia, è stato probabilmente più orientato ai thread (i thread sono utili per creare applicazioni reattive).

Disclaimer: non sono affatto un esperto in materia, quindi perdonami se ho sbagliato.

Uh, sembra che ci siano molte giustificazioni "è meglio così" in corso.

Penso che le persone potrebbero trarre beneficio dalla lettura di "Showstopper"; il libro sullo sviluppo di Windows NT.

L'intera ragione per cui i servizi vengono eseguiti come DLL in un processo su Windows NT è che erano troppo lenti come processi separati.

Se ti sporchi e ti sporchi, scoprirai che il problema è la strategia di caricamento della libreria.

Su Unix (in generale) i segmenti di codice delle librerie condivise (DLL) sono effettivamente condivisi.

Windows NT carica una copia della DLL per processo, poiché manipola il segmento di codice della libreria (e il segmento di codice eseguibile) dopo il caricamento. (Gli dice dove sono i tuoi dati?)

Ciò si traduce in segmenti di codice nelle librerie che non sono riutilizzabili.

Quindi, la creazione del processo NT è in realtà piuttosto costosa. E sul lato negativo, non rende apprezzabile il risparmio di memoria della DLL, ma una possibilità per problemi di dipendenza tra le app.

A volte in ingegneria paga fare un passo indietro e dire: "ora, se dovessimo progettarlo per fare davvero schifo, come sarebbe?"

Ho lavorato con un sistema incorporato che era piuttosto capriccioso una volta, e un giorno l'ho guardato e ho capito che era un magnetron a cavità, con l'elettronica nella cavità delle microonde. Lo abbiamo reso molto più stabile (e meno simile a un microonde).

La risposta breve è "livelli e componenti software".

L'architettura SW di Windows ha un paio di livelli e componenti aggiuntivi che non esistono su Unix o sono semplificati e gestiti all'interno del kernel su Unix.

Su Unix, fork ed exec sono chiamate dirette al kernel.

Su Windows, l'API del kernel non viene utilizzata direttamente, c'è win32 e alcuni altri componenti sopra di essa, quindi la creazione del processo deve passare attraverso livelli aggiuntivi e quindi il nuovo processo deve essere avviato o connettersi a quei livelli e componenti.

Per un po 'di tempo i ricercatori e le aziende hanno tentato di rompere Unix in un modo vagamente simile, basando solitamente i loro esperimenti sul kernel Mach ; un esempio ben noto è OS X .. Ogni volta che ci provano, però, diventa così lento che finiscono per unire almeno parzialmente i pezzi nel kernel in modo permanente o per le spedizioni di produzione.

Poiché sembra esserci qualche giustificazione di MS-Windows in alcune delle risposte, ad es

• “Il kernel NT e Win32 non sono la stessa cosa. Se programmi sul kernel NT, non è poi così male ”- Vero, ma a meno che tu non stia scrivendo un sottosistema Posix, allora chi se ne frega. Scriverai a win32.
• "Non è giusto confrontare il fork, con ProcessCreate, poiché fanno cose diverse e Windows non ha il fork" - Vero, quindi confronterò simili con simili. Tuttavia confronterò anche il fork, perché ha molti molti casi d'uso, come l'isolamento dei processi (ad esempio, ogni scheda di un browser web viene eseguita in un processo diverso).

Ora guardiamo ai fatti, qual è la differenza di prestazioni?

Dati estrapolati da http://www.bitsnbites.eu/benchmarking-os-primitives/ .
Poiché il bias è inevitabile, riassumendo, l'ho fatto a favore dell'hardware MS-Windows
per la maggior parte dei test i7 8 core 3.2GHz. Tranne Raspberry-Pi con Gnu / Linux

Note: su Linux, forkè più veloce del metodo preferito da MS-Window CreateThread.

Numeri per le operazioni del tipo di creazione del processo (perché è difficile vedere il valore per Linux nel grafico).

In ordine di velocità, dal più veloce al più lento (i numeri sono il tempo, piccolo è meglio).

• Linux CreateThread 12
• Mac CreateThread 15
• Forcella Linux 19
• Windows CreateThread 25
• Linux CreateProcess (fork + exec) 45
• Mac Fork 105
• Mac CreateProcess (fork + exec) 453
• Raspberry-Pi CreateProcess (fork + exec) 501
• Windows CreateProcess 787
• Windows CreateProcess con antivirus 2850
• Windows Fork (simula con CreateProcess + fixup) maggiore di 2850

Numeri per altre misurazioni

• Creazione di un file.
  • Linux 13
  • Mac 113
  • Windows 225
  • Raspberry-Pi (con scheda SD lenta) 241
  • Windows con defender e antivirus, ecc. 12950
• Allocazione della memoria
  • Linux 79
  • Windows 93
  • Mac 152

Tutto ciò in più c'è il fatto che sulla macchina Win molto probabilmente un software antivirus entrerà in funzione durante il CreateProcess ... Di solito è il rallentamento più grande.

Vale anche la pena notare che il modello di sicurezza in Windows è molto più complicato rispetto ai sistemi operativi basati su unix, il che aggiunge molto overhead durante la creazione del processo. Ancora un altro motivo per cui il multithreading è preferito al multiprocessing in Windows.