Tecnicamente, perché sono processi in Erlang più efficiente di discussioni OS?

https://stackoverflow.com/questions/2708033

01-10-2019
|

Domanda

Caratteristiche di Erlang

Erlang programmazione (2009):

Erlang concorrenza è veloce e scalabile. I suoi processi sono leggeri in quanto la macchina virtuale Erlang non crea un thread di sistema operativo per ogni processo creato. Essi vengono creati, programmati e gestiti in VM, indipendentemente dal sistema operativo sottostante. Come risultato, ora di creazione processo è dell'ordine dei microsecondi e indipendente dal numero di processi contemporaneamente esistenti. Confronta questo con Java e C #, dove per ogni processo viene creato un filo sistema operativo sottostante:. Otterrete alcuni confronti molto competitivi, con Erlang superando notevolmente entrambe le lingue

concorrenza Programmazione orientata Erlang (pdf ) (diapositive) (2003):

Si osserva che il tempo necessario per creare un processo Erlang è 1µs costanti fino a 2.500 processi; da allora in poi aumenta a circa 3µs per un massimo di 30.000 processi. Le prestazioni di Java e C # è visualizzato nella parte superiore della figura. Per un piccolo numero di processi ci vogliono circa 300µs per creare un processo. La creazione di più di duemila processi è impossibile.

Si vede che per un massimo di 30.000 processi il tempo di inviare un messaggio tra due Erlang processi è di circa 0.8µs. Per C # ci vogliono circa 50µs per messaggio, fino al numero massimo di processi (che era di circa 1800 processi). Java è stato anche peggio, per un massimo di 100 processo ci sono voluti circa 50µs per messaggio in seguito è aumentato rapidamente fino a 10ms per messaggio quando c'erano circa 1000 processi Java.

I miei pensieri

Io non capiscono fino in fondo tecnicamente il motivo per cui i processi di Erlang sono molto più efficienti nella deposizione delle uova nuovi processi e hanno impronte di memoria molto più piccole per processo. Sia il sistema operativo e Erlang VM hanno a che fare programmazione, cambi di contesto, e tenere traccia dei valori nei registri e così via ...

Semplicemente perché non sono le discussioni OS implementata nello stesso modo come processi in Erlang? Hanno per sostenere qualcosa di più? E perché hanno bisogno di un footprint di memoria più grande? E perché hanno più lenta deposizione delle uova e la comunicazione?

Tecnicamente, perché sono processi in Erlang più efficiente di thread del sistema operativo quando si tratta di deposizione delle uova e di comunicazione? E perché non possono thread nel sistema operativo essere implementati e gestiti allo stesso modo efficiente? E perché le discussioni OS hanno un ingombro di memoria più grande, più lenta la deposizione delle uova e la comunicazione?

Più lettura

Soluzione

Ci sono diversi fattori che contribuiscono:

Erlang non sono processi del sistema operativo. Essi sono attuate dal Erlang VM utilizzando un modello di filettatura cooperativo leggero (preventiva a livello Erlang, ma sotto il controllo di un runtime cooperativamente programmata). Ciò significa che è molto più economico al contesto interruttore, perché passare solo in punti noti, controllata e di conseguenza non è necessario salvare l'intero stato della CPU (normale, SSE e FPU registri, indirizzo di mappatura dello spazio, ecc.).
processi Erlang utilizzare pile allocati dinamicamente, che si aprono molto piccola e crescono come necessario. Questo permette la deposizione delle uova di molte migliaia - se non milioni -. Processi di Erlang, senza succhiare tutta la RAM disponibile
Erlang usato essere thread singolo, il che significa che non vi era alcuna necessità di garantire la thread safety tra processi. E 'ora supporta SMP, ma l'interazione tra Erlang processi sullo stesso scheduler / core è ancora molto leggero (non ci sono code run separati per core).

Altri suggerimenti

Dopo un po 'più ricerca ho trovato una presentazione da Joe Armstrong.

Erlang - software per un mondo concomitante (presentazione) (a 13 min):

[Erlang] è un linguaggio concorrente - con questo intendo dire che le discussioni sono parte del linguaggio di programmazione, non appartengono al sistema operativo. Questo è veramente ciò che c'è di sbagliato con i linguaggi di programmazione come Java e C ++. E 'thread non sono nel linguaggio di programmazione, le discussioni sono qualcosa nel sistema operativo - e si ereditano tutti i problemi che hanno nel sistema operativo. Uno dei problemi è la granularità del sistema di gestione della memoria. La gestione della memoria nel sistema operativo protegga intere pagine della memoria, quindi la dimensione più piccola che un thread può essere è il più piccolo formato di una pagina. che in realtà è troppo grande.

Se si aggiunge più memoria al vostro computer - avete lo stesso numero di bit che protegge la memoria in modo che la granularità delle tabelle delle pagine sale - si finisce per utilizzare diciamo 64kB per un processo si sa in esecuzione in poche centinaia di byte.

Credo che se non risponde a tutti, almeno alcune delle mie domande

Ho implementato coroutine in assembler, ei risultati misurati.

Il passaggio tra coroutine, processi Erlang note anche come, dura circa 16 istruzioni e 20 nanosecondi su un processore moderno. Inoltre, spesso si conosce il processo si sta passando (esempio: un processo di ricezione di un messaggio nella sua coda può essere implementato come straight hand-off dal processo chiamando al processo di ricezione) in modo che il programma di pianificazione non entra in gioco, facendo è un O (1) operazione.

Per le discussioni interruttore del sistema operativo, ci vogliono circa 500-1000 nanosecondi, perché si sta chiamando verso il basso per il kernel. La pianificazione dei thread del sistema operativo potrebbe essere eseguito in O (log (n)) o O (log (log (n))) il tempo, che inizierà ad essere evidente se si dispone di decine di migliaia, o addirittura milioni di fili.

Di conseguenza, i processi di Erlang sono più veloci e scala migliore perché sia ??il funzionamento fondamentale di commutazione è più veloce, e le piste di pianificazione meno spesso.

Erlang elabora corrispondono (circa) per fili verdi in altre lingue; non c'è nessuna separazione OS-forzata tra i processi. (Ci può ben essere la separazione dalla lingua forzata, ma questo è un minore di protezione nonostante Erlang facendo un lavoro meglio di più.) Perché sono così tanto più leggeri, possono essere usati molto più estesamente.

filettature OS dall'altro possono essere semplicemente previsto su diversi core della CPU, e sono (soprattutto) in grado di supportare l'elaborazione CPU-bound indipendente. I processi OS sono come fili OS, ma con molto più forte separazione OS-forzata. Il prezzo di queste funzionalità è che i thread del sistema operativo e (ancor più) i processi sono più costosi.

Un altro modo per capire la differenza è questa. Supponendo che si andavano a scrivere un'implementazione di Erlang in cima alla JVM (non un suggerimento particolarmente pazza) allora si sarebbe fare di ogni processo di Erlang essere un oggetto con qualche stato. Farebbe quindi avere un pool di istanze della discussione (tipicamente dimensionati in base al numero di core nel vostro sistema host, che è un parametro impostabile nel settore Erlang Runtime della BTW), che eseguire i processi Erlang. A sua volta, che distribuirà il lavoro che deve essere fatto attraverso le risorse reali di sistema disponibili. E 'un modo abbastanza pulito di fare le cose, ma si basa tutto sul fatto che ogni singolo processo Erlang non fa molto. Va bene, naturalmente; Erlang è strutturato per non richiede quei singoli processi per essere pesante poiché è l'insieme generale di loro che esegue il programma.

In molti modi, il vero problema è uno di terminologia. Le cose che Erlang chiama i processi (e che corrispondono con forza allo stesso concetto di CSP, CCS, ed in particolare il p-calcolo) non sono semplicemente le stesse cose che lingue con un patrimonio C (tra cui C ++, Java, C #, e molti altri) definiscono un processo o un thread. Ci sono alcuni somiglianze (tutti implicano una qualche nozione di esecuzione concorrente), ma non c'è assolutamente alcun equivalenza. Quindi state attenti quando qualcuno dice “processo” a voi; si potrebbe capire che significhi qualcosa di completamente diverso ...

Credo che Jonas ha voluto alcuni numeri sul confronto discussioni OS per processi di Erlang. L'autore di programmazione Erlang, Joe Armstrong, un po 'indietro testato la scalabilità della deposizione delle uova dei processi di Erlang a thread del sistema operativo. Ha scritto un semplice server web in Erlang e testato contro multi-threaded di Apache (in quanto Apache utilizza i thread del sistema operativo). C'è un vecchio sito web con i dati che risale al 1998. Sono riuscito solo per scoprire che il sito esattamente una volta. Quindi non posso fornire un collegamento. Ma l'informazione è là fuori. Il punto principale dello studio ha mostrato che Apache maxed poco meno di 8K processi, mentre il suo server di Erlang scritta a mano gestita 10K + processi.

A causa Erlang interprete deve solo preoccuparsi di se stessa, il sistema operativo ha molte altre cose di cui preoccuparsi.

uno dei motivi è processo erlang non viene creato nel sistema operativo, ma nel evm (erlang macchina virtuale), quindi il costo è minore.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow