modello per NET parallelismo di là di un singolo computer

Question

sospetto che presto esaurire la velocità migliorando le possibilità di filettatura su più core in un singolo computer.

Cosa tavolo del programmatore .NET bisogno di imparare a muoversi un problema parallelo realizzabile su più computer? La mia preferenza è di ridurre al minimo lo sforzo di programmazione del ciclo di vita totale, quindi sarebbe preferibile se ci fossero cambiamenti minimi tra la distribuzione locale e la distribuzione fuori sede.

Rispetto al programmatore di ore-uomo, è Linux, LAMP o qualche altra risma modo migliore di C# .NET su Windows per una tale domanda?

Edit: Alcune informazioni aggiuntive dai miei commenti qui sotto. La parte ad alta intensità di calcolo del problema può essere arbitrariamente grande così i costi generali da distribuire/ricombinare non sono un problema perché l'overhead sarà solo una piccola percentuale del tempo devi aspettare un risultato. Questo è un team di sviluppo one man. Solo un suggerimento e non so se è buono o no: come su WCF e XML come mezzo per distribuire il problema in modo completamente on-premise Azure-ignorante e la fiducia che si sarà (un giorno) il lavoro su Azure senza modifiche e senza i vantaggi di essere Azure consapevoli. Questo è solo un tutta da idea e spero che qualcuno ha un migliore, anche se non è una soluzione di Windows .

Un'altra modifica: Digipede ha un'offerta per il miglioramento delle prestazioni e un documento sulla distinzione tra un cluster e una griglia.

http://www.digipede.net/downloads/Digipede_CCS_Whitepaper.pdf

Dal momento che il mio problema è più di tipo grid di cluster e voglio farlo a buon mercato, io cerco solo l'approccio WCF.

Answer 1

La creazione di un meccanismo di calcolo della farm utilizzando WCF sarebbe IMO semplice. Poiché stai già utilizzando C# su Windows, questa è una progressione naturale, rispetto al cambio di lingua o stack tecnologico.

Un primo passo in questo processo sarebbe quello di progettare un meccanismo in base al quale i lavoratori di computer possono pubblicizzare la loro disponibilità su una macchina master. O il master dovrebbe avere una conoscenza apriori dei lavoratori, o (meglio) hanno bisogno di un meccanismo coerente per "localizzare" il server, ad es. in un dominio ben noto. Mettendo il master, ad esempio, www.all-your-cycles-belong-to-us.org, si dovrebbe disporre di un servizio WCF che offra offerte in arrivo di tempo di elaborazione. Se il tuo meccanismo di delega può adattarsi in base al numero di lavoratori, tanto meglio.

La definizione dei servizi, dei dati e dei contratti di guasto tra il Master e i lavoratori può richiedere alcuni esperimenti per ottenere il miglior equilibrio tra eleganza di programmazione, throughput computazionale e flessibilità/impermeabilità futura.

Per esperienza, il tipo di sfide di questo (e altri) sono approcci:

1. Worker va tranquillo.

   Se a causa di problemi di rete, essere "occupato" per lunghi periodi o tempi di inattività effettivi è difficile da dire fino a quando la comunicazione con il master può essere ristabilita. Nel mio lavoro giornaliero, abbiamo migliaia di macchine che "chiamano casa" periodicamente e che passano un'ora intera senza chiamare casa sono considerate "inattive". Dovresti impostare un altro lavoratore per fare lo stesso lavoro o aspettare una quantità arbitraria di tempo per completare l'originale? Solo tu conosci il tuo algoritmo, ma una combinazione di entrambi gli approcci può aiutare.

2. Abuso degli operai.

   Se il problema computazionale è veramente difficile, è possibile allineare la CPU su tutti i lavoratori. Questo sarebbe accettabile? Se stai affittando i cicli della CPU, allora si. Se stai facendo lo slooping di cicli di riserva su macchine inattive (a la SETI), allora no.

3. I risultati arrivano fuori servizio.

   Il set di risultati può essere riassemblato nell'ordine corretto dal master se diversi lavoratori terminano in momenti diversi?

4. Controllo del codice.

   Se si corregge il codice, come viene inviato a tutti i lavoratori per assicurarsi che abbiano la versione corretta? Ci sono molte opzioni per risolvere questo problema, ma vale la pena pensarci prima piuttosto che dopo.

5. Lavoratori dissimili.

   Avere un operatore multi-CPU top-of-the-line che partecipa alla farm di elaborazione insieme a macchine con CPU solo-core-solo-solista potrebbe produrre un comportamento bizzarro se non si sapesse che i lavoratori erano specifiche diverse. Adattare le tue interfacce WCF per consentire a un lavoratore di suggerire quanto carico potrebbe richiedere un certo valore.

Answer 2

Onestamente, direi che non c'è differenza tra le pile. La sfida che avrai è quella di interrompere il lavoro e ricostituire l'output di ciascuna macchina. Microsoft ha un HIV research project che fa esattamente quello che si desidera utilizzare la tecnologia .NET per "divide et impera" un grande problema computazionale.

Answer 3

Consiglierei di leggere le tecnologie CCR e DSS di Microsoft. È un'implementazione davvero piacevole di parallelizzare inviando parti di lavoro a "porte". Queste porte vengono lette da worker (thread) che come effetto aggiunto rendono davvero efficace l'uso dei core disponibili.

Il DSS è un ulteriore livello che semplifica l'utilizzo dello stesso concetto su più macchine.

una bella introduzione può essere letto qui: concurrent affairs

una bella libreria di terze parti xcoappspace è disponibile come un'implementazione alternativa di comunicazione trasversale computer in base al rischio di controparte. Penso che sia ancora più facile del dss.Un bel articolo da leggere dopo aver terminato l'articolo CCR; ^) xcoappspace

un sacco di questi concetti sono stati reso popolare dal linguaggio Erlang.

Answer 4

La cosa principale da tenere in considerazione quando ci si sposta da un multi-thread a un computing distribuito è il sovraccarico maggiore per lo spooling dei lavori su macchine remote rispetto allo spooling di un altro thread sul computer corrente. La granularità degli elementi di lavoro deve essere sufficientemente ampia da giustificare una comunicazione significativamente più lenta tra i nodi: la messaggistica tra i thread sullo stesso computer è di molti ordini di grandezza più veloce della messaggistica tra diversi computer sulla rete.

La condivisione delle risorse è più difficile tra le macchine. La condivisione di oggetti in memoria è semplice in più thread nello stesso processo, ma richiede un po 'di ingegneria per ottenere risultati simili su tutte le macchine. I blocchi non esistono fondamentalmente tra le macchine. Cerca di utilizzare un servizio/server di messaggi in coda per coordinare il lavoro tra più macchine, restituire i risultati all'aggregatore, ecc.

Si menziona "on premises vs off premises". Se si stanno prendendo in considerazione le risorse di calcolo fuori sede, assicurarsi di cercare i fornitori di servizi di cloud computing o di calcolo elastico. Stranamente, questi non vengono utilizzati nello stesso respiro della programmazione parallela come spesso si penserebbe. Il cloud computing ti offre la possibilità di ridimensionare il tuo parallelismo fino a centinaia o migliaia di nodi di calcolo che paghi solo mentre li stai effettivamente utilizzando. Al termine del calcolo o alla fonte in tempo reale in cui i dati da analizzare tornano a casa alla fine della giornata, è possibile "spegnere" i nodi cloud e arrestare l'orologio della fatturazione fino a quando non vengono riavviati.

Amazon, Google e Microsoft sono tre grandi fornitori di servizi cloud (tra gli altri) e ciascuno ha caratteristiche, punti di forza e punti deboli molto diversi. Lavoro su materiale di Azure in Microsoft. Le code di messaggi incorporate di Azure sono piuttosto lisce per l'esecuzione di flussi di lavoro di produttori/consumatori su larga scala.

Se si utilizza LAMP o .NET come piattaforma, le informazioni sulle prestazioni e molto altro sugli strumenti e le competenze che si hanno all'interno del proprio team di sviluppo sono davvero inferiori. La scelta deliberata di una piattaforma di destinazione che non corrisponde al set di abilità del team di sviluppo è un ottimo modo per aggiungere un sacco di tempo e riqualificare i costi per la pianificazione del progetto.

C# /. NET funziona molto bene per la codifica di sistemi paralleli rispetto a C++ o script in altri ambienti. Prendi in considerazione le funzionalità linguistiche, gli strumenti di debug e le librerie e i servizi predefiniti disponibili quando valuti quale piattaforma è più adatta alle tue competenze e alla progettazione del sistema desiderata.