Tecnicamente, perché i processi in Erlang sono più efficienti dei thread del sistema operativo?

Caratteristiche di Erlang

Da Erlang Programming (2009):

La concorrenza di Erlang è veloce e scalabile. I suoi processi sono leggeri in quanto la macchina virtuale Erlang non crea un thread del sistema operativo per ogni processo creato. Vengono creati, pianificati e gestiti nella VM, indipendentemente dal sistema operativo sottostante. Di conseguenza, il tempo di creazione del processo è dell'ordine dei microsecondi e indipendente dal numero di processi esistenti contemporaneamente. Confronta questo con Java e C #, dove per ogni processo viene creato un thread del sistema operativo sottostante: otterrai alcuni confronti molto competitivi, con Erlang che supera notevolmente entrambe le lingue.

Dalla programmazione orientata alla concorrenza in Erlang (pdf) (diapositive) (2003):

Osserviamo che il tempo impiegato per creare un processo Erlang è costante 1µs fino a 2.500 processi; successivamente aumenta a circa 3µs per un massimo di 30.000 processi. Le prestazioni di Java e C # sono mostrate nella parte superiore della figura. Per un numero limitato di processi sono necessari circa 300 µs per creare un processo. La creazione di oltre duemila processi è impossibile.

Vediamo che per un massimo di 30.000 processi il tempo per inviare un messaggio tra due processi Erlang è di circa 0,8 µs. Per C # sono necessari circa 50 µs per messaggio, fino al numero massimo di processi (che era di circa 1800 processi). Java era anche peggio, per un massimo di 100 processi ci sono voluti circa 50 µs per messaggio, successivamente è aumentato rapidamente a 10 ms per messaggio quando c'erano circa 1000 processi Java.

I miei pensieri

Tecnicamente non capisco perfettamente perché i processi Erlang siano molto più efficienti nel generare nuovi processi e abbiano impronte di memoria molto più piccole per processo. Sia il sistema operativo che la VM Erlang devono eseguire la pianificazione, i cambi di contesto e tenere traccia dei valori nei registri e così via ...

Semplicemente perché i thread del sistema operativo non sono implementati allo stesso modo dei processi in Erlang? Devono supportare qualcosa in più? E perché hanno bisogno di un footprint di memoria maggiore? E perché hanno una generazione e una comunicazione più lente?

Tecnicamente, perché i processi in Erlang sono più efficienti dei thread del sistema operativo quando si tratta di spawn e comunicazione? E perché i thread nel sistema operativo non possono essere implementati e gestiti nello stesso modo efficiente? E perché i thread del sistema operativo hanno un footprint di memoria maggiore, oltre a una generazione e una comunicazione più lente?

Più lettura

• All'interno della VM Erlang con focus su SMP (2008)
• Concorrenza in Java e in Erlang (pdf) (2004)
• Misurazioni delle prestazioni di thread in Java e processi a Erlang (1998)

Esistono diversi fattori che contribuiscono:

1. I processi Erlang non sono processi OS. Sono implementati dalla VM Erlang utilizzando un modello di threading cooperativo leggero (preventivo a livello di Erlang, ma sotto il controllo di un runtime pianificato in modo cooperativo). Ciò significa che è molto più economico cambiare contesto, perché cambiano solo in punti noti e controllati e quindi non devono salvare l'intero stato della CPU (normale, registri SSE e FPU, mappatura dello spazio degli indirizzi, ecc.).
2. I processi di Erlang utilizzano stack allocati dinamicamente, che iniziano molto piccoli e crescono se necessario. Ciò consente la generazione di molte migliaia - persino milioni - di processi Erlang senza risucchiare tutta la RAM disponibile.
3. Erlang era a thread singolo, il che significa che non era necessario garantire la sicurezza del thread tra i processi. Ora supporta SMP, ma l'interazione tra i processi Erlang sullo stesso scheduler / core è ancora molto leggera (ci sono code di esecuzione separate per core).

Dopo qualche altra ricerca ho trovato una presentazione di Joe Armstrong.

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

[Erlang] è un linguaggio concorrente - intendo dire che i thread fanno parte del linguaggio di programmazione, non appartengono al sistema operativo. Questo è davvero ciò che non va nei linguaggi di programmazione come Java e C ++. I thread non sono nel linguaggio di programmazione, i thread sono qualcosa nel sistema operativo e 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 protegge intere pagine di memoria, quindi la dimensione più piccola che può essere un thread è la dimensione più piccola di una pagina. In realtà è troppo grande.

Se aggiungi più memoria alla tua macchina - hai lo stesso numero di bit che protegge la memoria e quindi aumenta la granularità delle tabelle di pagine - finisci per usare 64kB per un processo che conosci in esecuzione in poche centinaia di byte.

Penso che risponda se non tutte, almeno alcune delle mie domande

Ho implementato coroutine in assemblatore e misurato le prestazioni.

Il passaggio tra coroutine, noti anche come processi Erlang, richiede circa 16 istruzioni e 20 nanosecondi su un moderno processore. Inoltre, spesso conosci il processo a cui stai passando (esempio: un processo che riceve un messaggio nella sua coda può essere implementato come passaggio diretto dal processo di chiamata al processo di ricezione) in modo che lo scheduler non entri in gioco, rendendo è un'operazione O (1).

Per cambiare i thread del sistema operativo, ci vogliono circa 500-1000 nanosecondi, perché stai chiamando il kernel. L'utilità di pianificazione dei thread del sistema operativo potrebbe essere eseguita in O (log (n)) o O (log (log (n))), il che inizierà a essere evidente se si hanno decine di migliaia o addirittura milioni di thread.

Pertanto, i processi Erlang sono più veloci e si adattano meglio perché entrambe le operazioni fondamentali di commutazione sono più veloci e lo scheduler viene eseguito meno spesso.

I processi di Erlang corrispondono (approssimativamente) a fili verdi in altre lingue; non esiste una separazione forzata del sistema operativo tra i processi. (Potrebbe esserci una separazione forzata dal linguaggio, ma questa è una protezione minore nonostante Erlang svolga un lavoro migliore rispetto alla maggior parte.) Poiché sono molto più leggeri, possono essere utilizzati molto più ampiamente.

D'altra parte, i thread del sistema operativo possono essere semplicemente programmati su diversi core della CPU e sono (principalmente) in grado di supportare l'elaborazione indipendente legata alla CPU. I processi del sistema operativo sono come thread del sistema operativo, ma con una separazione forzata del sistema operativo molto più forte. Il prezzo di queste funzionalità è che i thread del sistema operativo e (e ancora di più) i processi sono più costosi.

Un altro modo per capire la differenza è questo. Supponendo che stavi per scrivere un'implementazione di Erlang in cima alla JVM (non un suggerimento particolarmente pazzo), allora faresti in modo che ogni processo di Erlang sia un oggetto con un certo stato. Avresti quindi un pool di istanze di Thread (in genere dimensionate in base al numero di core nel tuo sistema host; questo è un parametro sintonizzabile in runtime reale Erlang BTW) che eseguono i processi Erlang. A sua volta, ciò distribuirà il lavoro da svolgere attraverso le risorse di sistema reali disponibili. È un modo piuttosto semplice di fare le cose, ma si affida completamentesul fatto che ogni singolo processo di Erlang non fa molto. Va bene ovviamente; Erlang è strutturato in modo da non richiedere che quei singoli processi siano pesanti poiché è il loro insieme generale che esegue il programma.

In molti modi, il vero problema è quello della terminologia. Le cose che Erlang chiama processi (e che corrispondono fortemente allo stesso concetto in CSP, CCS, e in particolare il calcolo π) non sono semplicemente le stesse che le lingue con un patrimonio C (inclusi C ++, Java, C # e molti altri) chiamano un processo o un thread. Ci sono alcune somiglianze (tutte implicano una nozione di esecuzione simultanea) ma sicuramente non c'è equivalenza. Quindi fai attenzione quando qualcuno ti dice "process"; potrebbero capirlo per significare qualcosa di completamente diverso ...

Penso che Jonas volesse alcuni numeri nel confrontare i thread del sistema operativo con i processi Erlang. L'autore di Programming Erlang, Joe Armstrong, qualche tempo fa ha testato la scalabilità della generazione dei processi Erlang sui thread del sistema operativo. Ha scritto un semplice server Web in Erlang e lo ha testato su Apache multi-thread (poiché Apache utilizza thread del sistema operativo). C'è un vecchio sito web con i dati risalenti al 1998. Sono riuscito a trovarlo solo una volta. Quindi non posso fornire un link. Ma l'informazione è là fuori. Il punto principale dello studio ha mostrato che Apache ha raggiunto il limite massimo di 8K processi, mentre la sua mano scritta sul server Erlang ha gestito processi 10K +.

Poiché l'interprete Erlang deve solo preoccuparsi di se stesso, il sistema operativo ha molte altre cose di cui preoccuparsi.

uno dei motivi è che il processo erlang non viene creato nel sistema operativo, ma in evm (erlang virtual machine), quindi il costo è inferiore.