quante CPU sono necessari prima che Erlang è più veloce rispetto a thread singolo Java

Question

Attualmente sto usando Java, ho letto molto su Erlang in rete, e ho 2 grandi domande:

1. Come molto più lento (se mai) sarà Erlang rispetto a Java semplice?
   Suppongo qui che Java sarà più veloce dallo shootout benchmarks sulla rete (Erlang non funziona bene). Quindi, quante altre CPU avrò bisogno di far splendere Erlang su Java a thread singolo (nella mia particolare situazione, data sotto)?

2. Dopo aver letto per un po 'di tempo su Erlang, ho trovato un numero di commenti/post che dicono che i sistemi Erlang più grandi contengono una buona quantità di C/C++.
   È per motivi di velocità (la mia ipotesi) o qualcos'altro? cioè, perché è richiesto?

Ho letto sul numero di processori in maggior parte delle macchine che vanno in su e filettatura modelli essendo difficile (sono d'accordo), ma sto cercando di scoprire quando la "linea" sta per essere attraversato in modo che io possa cambia lingua/paradigma al momento giusto.

Un po 'di fondo/contesto:
sto lavorando sul lato server sui servizi Java che sono molto CPU-bound e facilmente fatta in parallelo. Ciò è dovuto, in genere, a un singolo aggiornamento in entrata (via TCP) che attiva una modifica a più uscite (100 s).

I calcoli sono in genere piuttosto semplici (pochi cicli, solo un sacco di operazioni aritmetiche) e gli input stanno arrivando abbastanza velocemente (100/s).

Attualmente stiamo eseguendo su 4 macchine CPU e eseguendo più servizi su ciascuna (quindi multi-threading è piuttosto inutile e Java sembra funzionare più velocemente senza i blocchi di sincronizzazione, ecc. Necessari per renderlo multi-thread). Ora c'è una forte spinta alla velocità e ora abbiamo accesso a 24 processori (per processo, se necessario), quindi mi chiedo come meglio procedere: Java multi-threading o qualcosa di più facile da codificare, come Erlang.

Answer 1

poiché si tratta di un carico di lavoro aritmetico e si è già lavorato per dividere il codice in processi di servizio separati, non si otterrebbe molto da Erlang. Il tuo lavoro sembra adattarsi perfettamente a Java. Erlang è bravo a transazioni minuscole, come il passaggio da un messaggio all'altro o la pubblicazione di pagine web statiche o semplici-dinamiche. Non esattamente il carico di lavoro del numero aziendale o del database.

Tuttavia, si potrebbe costruire sulle biblioteche numerici esterni e database e utilizzare Erlang come MSG interruttore: D è quello che divano-db fa: P

- modifica -

1. Se spostare le tue operazioni aritmetiche in un Erlang async-IO driver erlang sarà altrettanto buono come il linguaggio sparato - roba - ma con 24 cpu forse non importa più di tanto; il database di erlang è procedurale e quindi abbastanza veloce - questo può essere sfruttato nella tua applicazione aggiornando 100 entità su ogni transazione.

2. Il sistema di runtime erlang deve essere un misto di C e C++ perché (a) l'emulatore di erlang è scritto in C/C++ (devi iniziare da qualche parte), (b) devi parlare con il kernel per fare un file async io e network io, e (c) alcune parti del sistema devono essere rapidamente vesciche --eg, il backend del sistema di database (amnesia).

- discussione -

con 24 CPU in una topologia 6 nucleo * 4 CPU utilizzando un bus di memoria condivisa - Hai 4 entità NUMA (la CPU) e una memoria centrale. Devi essere saggio riguardo al paradigma, l'approccio multi-processo condiviso-nulla potrebbe uccidere il tuo bus di memoria.

Per aggirare questo è necessario creare 4 processi con 6 thread di elaborazione e associare ogni thread di elaborazione al core corrispondente nella CPU corrispondente. Questi 6 thread devono fare multi-threading collaborativo - Erlang e Lua hanno questo innato - Erlang lo fa in modo hard-core in quanto ha uno scheduler completo come parte del suo runtime che può essere utilizzato per crearne tanti processi come vuoi

Ora, se dovessi suddividere le tue attività tra i 4 processi (1 per CPU fisica) saresti un uomo felice, tuttavia stai utilizzando 4 Java VM che fanno (presumibilmente) un lavoro serio (schifo, per molte ragioni). Il problema deve essere risolto con una migliore capacità di troncare e risolvere il problema.

In arrivo il sistema Erlang OTP, è stato progettato per sistemi di rete ridondanti robusti, ma ora si sta muovendo verso CPU NUMA-esque della stessa macchina. Ha già un emulatore SMP kick-ass e presto diventerà anche NUMA. Con questo paradigma di programmazione hai molte più possibilità di saturare i tuoi potenti server senza uccidere il tuo bus.

Forse questa discussione è stata teorica; tuttavia, quando si ottiene una topologia 8x8 o 16x8, si sarà pronti anche per questo. Quindi la mia risposta è quando si hanno più CPU 2 - moderne - fisiche sulla scheda madre, probabilmente si dovrebbe considerare un migliore paradigma di programmazione.

Come esempio di un prodotto principale seguito alla discussione qui: Microsoft's SQL Server is CPU-Level NUMA-aware in the SQL-OS layer su cui è stato creato il motore del database.

Answer 2

Hai confrontato il costo del nuovo hardware rispetto al costo del personale di riqualificazione in Erlang e ri-architetti il ​​tuo software in una nuova lingua?

non vorrei sottovalutare la spesa di riqualificazione te stesso (o altri) ed il costo di noleggio di persone dimestichezza in Erlang (che stanno per essere un molto più difficile da trovare di quanto la gente Java). I server ovviamente costano in termini di costi di archiviazione/alimentazione/manutenzione ecc., Ma sono comunque molto più economici di personale qualificato. Se puoi progredire e rimanere scalabile mentre usi i tuoi attuali skillset, sospetto che sia l'approccio più pragmatico.

Answer 3

Se ottieni 100 al secondo ma ne prendono 100 ciascuno come può tenere il passo? Forse sto fraintendendo quella parte, ma comunque a meno che non siano migliaia o milioni di richieste al secondo il tuo codice di sincronizzazione non dovrebbe richiedere molto tempo. Se lo è, stai facendo qualcosa di sbagliato, possibilmente bloccando mentre esegui l'intero lavoro o qualcosa del genere.

Per il codice multithreading, passare a un livello ancora più alto è probabilmente un errore. Anche se si scrive la parte dell'applicazione in erlang o qualunque cosa il multithreading dovrebbe probabilmente essere in Java o passare a C++ se le prestazioni diventano davvero un problema.

Answer 4

La questione della velocità quando si tratta di programmare i linguaggi è tanto complessa quanto una domanda. I sostenitori di Java possono indicare molte aree e affermare di essere più veloci e sarebbero corrette al 100%. I sostenitori di Ruby/Python indicano un diverso insieme di parametri e affermano di essere più veloci e sarebbero anche corretti. I sostenitori di Erlang puntano poi a connessioni concorrenti e affermano di essere i più veloci quando si tratta di centinaia o migliaia di connessioni o calcoli simultanei e non sarebbe sbagliato neanche.

Guardando la descrizione di base del progetto in questione mi sembra che Erlang sarebbe perfetto per le vostre esigenze. Non conoscendo i dettagli, direi che questo sarebbe in realtà un maledetto programma Erlang e potrebbe essere fatto in brevissimo tempo.

Answer 5

Dipende da diversi fattori. La risposta rapida è che sarà necessario confrontare ogni singolo programma per capire dove si trova la filigrana di quiescenza.

Ecco alcuni degli aspetti rilevanti che potrebbero avere un impatto che il rapporto beneficio:

1) Dipendenze computazionale: se il flusso logico ha molte dipendenze a risorse esterne (DBMS, l'accesso al disco, networking). Maggiore è la quantità di dipendenze computazionali che sono divisibili nell'elaborazione simultanea, maggiore è il vantaggio dell'adozione di una piattaforma di calcolo distribuita come erlang.

2) atomicity flusso logico: se il programma deve passare una grande quantità di tempo di calcolo su un singolo controllo sequenziale flusso sincrono e che non può essere suddiviso in più piccoli segmenti logici di codice. Più grande è l'atomicità del codice, meno può essere suddiviso in flussi di diffusione della CPU.

3) Condivisione di stati overhead: maggiore è la quantità di dati che deve essere distribuita tra le varie funzioni, maggiore è il sovraccarico che il framework richiede per trasmettere e ricevere semplicemente lo stato. In altre parole, se si inviano ripetutamente grandi quantità di dati senza un'area comune della cache condivisa, i benefici diminuiranno, sebbene questo abbia approcci diversi a seconda dei modelli di programmazione adottati.

Pertanto, date le vaste possibilità e variazioni basate su criteri come sopra, non è possibile avere una stima comune accettabile per tutti gli scenari.