Prestazioni di software simultaneo su processori multicore [chiuso]

Question

Prestazioni di software simultaneo su processori multicore [chiuso]

#1 da (4 voti)
#2 da (2 voti)

2

Recentemente ho letto spesso che, dato che la tendenza è quella di costruire processori con più core, sarà sempre più importante avere linguaggi di programmazione che supportano la programmazione simultanea e parallela per sfruttare al meglio il parallelismo offerto da questi processori (vedi ad esempio questo video per alcuni sfondo.).

A tale riguardo, alcuni paradigmi o modelli di programmazione sono considerati adatti per scrivere software concorrente solido:

Linguaggi di programmazione funzionale, ad es. Haskell, Scala, ecc.
Il modello attore: Erlang, ma disponibile anche per Scala / Java (Akka), C ++ (Theron, Casablanca, ...) e altri linguaggi di programmazione.

Le mie domande:

Qual è lo stato dell'arte riguardante lo sviluppo di applicazioni concorrenti (ad esempio utilizzando multi-threading) utilizzando i linguaggi / i modelli sopra indicati? Questa zona è ancora in fase di studio o esistono già pratiche consolidate?
Sarà più complesso programmare applicazioni con un livello più alto di concorrenza, o si tratta solo di imparare nuovi paradigmi e pratiche?
In che modo le prestazioni del software altamente concorrente si confrontano con le prestazioni di un software più tradizionale quando vengono eseguite su processori core multipli?
Ad esempio, qualcuno ha implementato un'applicazione desktop usando C ++ / Theron o Java / Akka? C'è stato un aumento delle prestazioni su un processore multi core a causa del parallelismo più elevato?

Modifica

NOTA che non sto chiedendo le tue opinioni o il tuo dibattito ma esperienze o informazioni concrete. Ad esempio, qualcuno ha scritto un programma Scala o Haskell, lo ha compilato con compilatori all'avanguardia e

Eseguilo su un Intel Core i3 e misurava una certa prestazione (ad esempio 10 secondi su determinati dati di input).
Esegui lo stesso bytecode o binario su un Intel Core i5 e osserva un aumento delle prestazioni (ad esempio 6 secondi di tempo di esecuzione) a causa del calcolo parallelo delle sottoespressioni che è possibile nel codice funzionale?

EDIT 2

RIASSUNTIVA. Fino ad ora realizzare processori più veloci significava aumentare la velocità di clock e non erano necessari cambiamenti nel paradigma di programmazione. Negli ultimi anni fare un processore più veloce ha comportato l'aggiunta di più core, ma ciò richiede che scriviamo software in modo diverso. La mia domanda è se gli sviluppatori software stanno iniziando a passare a nuovi paradigmi di programmazione e se questo sta portando il previsto aumento delle prestazioni su processori multi-core.

functional-programming concurrency haskell scala erlang

posta Giorgio 08.07.2012 - 00:55

fonte

2 risposte

Leggi altre domande sui tag functional-programming concurrency haskell scala erlang

un singolo file js compresso VS file di modulo requirejs compressi Ottieni l'attribuzione quando altre persone usano il mio codice

score 4 · Answer 1

(Questa non è una risposta completa, ma sembra troppo lunga per rientrare in un commento.)

Ci sono molti fattori che influenzano il tasso di adozione di "Design per il parallelismo" nel settore del software. Alcuni di loro non avevano nulla a che fare con i benefici. Ad esempio, le competenze e i livelli di conoscenza degli sviluppatori, ecc.

Una delle mie osservazioni è che il tipo di applicazione determina il suo tasso di adozione del paradigma parallelo. Ogni linea di prodotto software (livello) o componente ha uno o più "dominio / paradigma naturale"; cioè, il software sarebbe molto più facile da sviluppare e mantenere se fosse implementato in un particolare paradigma.

Se è necessario un cambio di paradigma per parallelizzare una determinata applicazione, è probabile che le società di software non trovino che sia economicamente conveniente giustificare. Se quel particolare paradigma è facilmente parallelizzabile, allora quello che vedi è che quei software avrebbero una maggiore velocità di adozione per la programmazione parallela.

Per quanto riguarda l'elenco dei paradigmi, vorrei aggiungere Dataflow. Tutti i compiti sono dichiarati in anticipo. Ogni attività dichiara i suoi input e output prima dell'esecuzione. Un'attività viene avviata non appena tutti i dati di input sono disponibili.

Esempi di paradigma Dataflow:

Risposta 1:

Avere un paradigma di grande successo non è abbastanza. Per far crescere il tasso di adozione della programmazione parallela, il parallelismo deve essere introdotto anche in altri paradigmi (compresi quelli "obsoleti").

Ho visto altri che hanno implementato con successo il parallelismo in un programma di interfaccia grafica di Windows, creando una finestra di dialogo di Windows (ogni finestra di dialogo di Windows è contenuta in un thread) per attività di calcolo e scambiando dati utilizzando i messaggi di Windows.

Risposta 2:

Ciò riecheggia la mia osservazione precedente: se l'introduzione del parallelismo in un'applicazione richiede che l'applicazione venga riscritta in un paradigma innaturale, la complessità dello sviluppo e della manutenzione verrà aumentata.

Risposta 3:

Per compiti puramente computazionalmente intensi, il guadagno di prestazioni di solito corrisponde molto strettamente alla previsione della Legge di Amdahl, a condizione che tutto il calcolo sia fatto localmente su un computer (cioè non soggetto al traffico I / O di rete molto più lento. )

Detto questo, scoprirai rapidamente che esistono colli di bottiglia non parallelizzabili nelle tue applicazioni. A volte questi colli di bottiglia sono teoricamente non parallelizzabili, il che significa che non c'è speranza di trovare un algoritmo migliore.

Risposta 4:

Una storia personale. Ho scritto un semplice programma in parallelo che decodifica un file JPEG, lo ridimensiona e poi lo salva in un formato di file immagine personalizzato. Dopo aver provato, ho trovato che il programma impiega 1,6 secondi per terminare, quando testato usando 3 thread o 4 thread. Si scopre che il passo di decodifica JPEG sta prendendo più del 25% del tempo, rendendolo il passo più lento non parallelizzabile.

In altre parole, la legge di Amdahl ha effetto con solo 3-4 core CPU per il mio piccolo programma.

A volte questi colli di bottiglia possono essere rimossi se ti è permesso modificare i requisiti del software (ad esempio, se puoi richiedere ai tuoi clienti di non di utilizzare un particolare formato di immagine), ma il più delle volte il i requisiti sono definiti in pietra.

score 2 · Answer 2

Non puoi magicamente creare codice non scritto per il lavoro di concorrenza in modo concorrente (e magicamente include l'uso di compilatori).

Molte volte le condizioni sono cambiate e il codice necessario per essere fatto in modo diverso. Nei vecchi tempi, la memoria era un premio, quindi il codice auto-modificante era comune. In questi giorni, i vantaggi del codice in memoria essendo di sola lettura sono così grandi che tutti i sistemi operativi moderni vogliono applicarlo.

Pensa anche a cosa è successo quando Windows è diventato popolare. Tutti i programmatori di DOS dovevano riconsiderare i loro modi di programmazione. Non è possibile avere un singolo ciclo di polling della tastiera che richiama la funzionalità completa dell'applicazione in un singolo programma a thread: è necessario disporre di gestori di eventi, che a loro volta hanno cambiato il modo in cui il codice dell'applicazione è stato progettato.

Mantra come "usa oggetti immutabili!" sono esperienze apprese nel modo più duro. I motivi per cui sono spesso persi per strada ma possono essere ricostruiti. L'opzione "Usa oggetti immutabili" è un modo semplice per consentire la memorizzazione nella cache di dati in più posizioni senza che il tuo programma si interrompa quando uno di questi luoghi viene aggiornato.

La modifica necessaria per essere concomitante non ha bisogno di essere una riscrittura completa in un linguaggio funzionale, ma può essere risolta con le librerie - che consente di conservare le librerie di codice esistenti - ma è comunque necessario scrivere il programma per utilizzarlo. L'approccio OpenCL (Grand Central in OS X) è un modo molto interessante per utilizzare sia CPU che GPU per eseguire il codice, ma ancora una volta è necessario impostare il programma di conseguenza.

In Java sono stati spesi molti sforzi per fornire buoni elementi costitutivi per ridimensionare in modo trasparente l'esecuzione di piccoli frammenti di codice, ma non è possibile utilizzarlo se non si scrive per questo.