I processori stanno ottenendo sempre più core in questi giorni, il che mi lascia chiedendo ...
Noi programmatori dovremmo adattarci a questo comportamento e dedicare maggiori sforzi alla programmazione per più core?
In che misura dovremmo fare e ottimizzare questo? Filo? Affinità? Ottimizzazioni hardware? Qualcos'altro?
Risposte:
Non importa quanto tu sia bravo, sarà improbabile che ti venga in mente uno schema migliore di gestione dei thread ecc. Rispetto ai team che sviluppano la lingua e il compilatore in cui stai scrivendo il tuo codice.
Se hai bisogno che la tua applicazione sia multi-thread, crea i thread che ti servono e lascia che compilatore e sistema operativo proseguano con i loro lavori.
Devi essere consapevole di come sono gestiti questi thread in modo da poter sfruttare al meglio le risorse. Non creare troppi thread è una cosa che viene in mente come esempio.
Devi anche essere consapevole di ciò che sta succedendo (vedi il commento di Lorenzo) in modo da poter fornire suggerimenti per la gestione del thread (o sovrascriverlo in casi speciali), ma avrei pensato che questi sarebbero pochi e rari.
Sono un programmatore .NET e so che .NET ha un'astrazione di alto livello per il multithreading chiamato Tasks. Ti protegge dal dover sapere troppo su come eseguire il multithreading corretto contro il metallo. Presumo che le altre piattaforme di sviluppo attuali abbiano astrazioni simili. Quindi, se hai intenzione di fare qualcosa con il multithreading, proverei a lavorare a quel livello, se possibile.
Ora, alla domanda di dovresti anche preoccuparti del multithreading nella tua particolare applicazione. La risposta a questa domanda dipende molto dall'applicazione che stai scrivendo. Se stai scrivendo un'applicazione che esegue l'elaborazione su migliaia (o più) cose indipendenti e questa elaborazione può essere eseguita in parallelo, quasi sicuramente otterrai un vantaggio dal multithreading. Tuttavia, se stai scrivendo una semplice schermata di immissione dei dati, il multithreading potrebbe non acquistarti molto.
Per lo meno, devi occuparti del multithreading quando lavori su un'interfaccia utente. Non vuoi interrompere un'operazione di lunga durata dall'interfaccia utente e farla non rispondere perché hai dirottato il thread dell'interfaccia utente per eseguire tale operazione. Attiva un thread in background e almeno assegna all'utente un pulsante Annulla in modo che non debbano attendere il completamento per un errore.
Nella terra di Objective-C e Mac OS X e iOS, i framework (come molti altri) sono scritti per sfruttare questi aumenti nei core del processore e presentare allo sviluppatore una bella interfaccia per farne uso.
Esempio su Mac OS X e iOS è la spedizione Grand Central. Ci sono aggiunte a libc(credo) per facilitare il multi-threading basato sulla coda. Quindi i framework Cocoa e Foundation (tra gli altri) sono scritti su GCD, offrendo allo sviluppatore un facile accesso alle code di invio e al threading con pochissimo codice della piastra di caldaia.
Molte lingue e framework hanno concetti simili.
La parte difficile consiste nel dividere l'algoritmo ad alta intensità di CPU in blocchi di esecuzione che potrebbero essere sottoposti a thread.
Quindi, un thread che salta continuamente da un core all'altro avrà delle penalità di prestazione (dovute alla cache della CPU di primo e secondo livello mancata), specialmente nelle architetture in cui sono impiegati due stampi fisici distinti. In questo caso l'affinità thread-core è una buona cosa.
Siamo ora (ottobre 2010) in un momento di immensa transizione.
Oggi potremmo acquistare un desktop a 12 core.
Oggi potremmo acquistare una scheda di elaborazione core 448 (ricerca di NVidia Tesla).
Ci sono limiti a quanto noi sviluppatori possiamo lavorare nell'ignoranza degli ambienti tremendamente paralleli in cui i nostri programmi lavoreranno nel prossimo futuro.
I sistemi operativi, gli ambienti di runtime e le librerie di programmazione possono fare solo così tanto.
In futuro, dovremo dividere la nostra elaborazione in blocchi discreti per l'elaborazione indipendente, utilizzando astrazioni come il nuovo "Task Framework" .NET.
Dettagli come la gestione della cache e l'affinità saranno ancora presenti, ma saranno solo la prova dell'applicazione ultra performante. Nessuno stesso sviluppatore vorrà gestire questi dettagli manualmente su una macchina core 10k.
beh, dipende davvero da cosa stai sviluppando. la risposta, a seconda di ciò che stai sviluppando, può variare da "è insignificante" a "è assolutamente fondamentale, e ci aspettiamo che tutti i membri del team abbiano una buona comprensione e un uso delle implementazioni parallele".
nella maggior parte dei casi, una solida comprensione e utilizzo di blocchi, thread, attività e pool di attività sarà un buon inizio quando è necessaria la necessità di parallelismo. (varia in base a lang / lib)
a ciò si aggiungono le differenze nei progetti che è necessario apportare: per il multiprocessing non banale si devono spesso apprendere diversi nuovi modelli di programmazione o strategie di parallelizzazione. in tal caso, il tempo per imparare, per fallire abbastanza tempo per avere una solida comprensione e per aggiornare i programmi esistenti può richiedere una squadra un anno (o più). una volta raggiunto quel punto, (si spera!) non perderete né affronterete problemi / implementazioni come fate oggi (a condizione che non abbiate ancora fatto quella transizione).
un altro ostacolo è che stai effettivamente ottimizzando un programma per una certa esecuzione. se non ti viene concesso molto tempo per ottimizzare i programmi, non ne trarrai alcun vantaggio quanto dovresti. la parallelizzazione di alto livello (o ovvio) può migliorare la velocità percorsa del tuo programma con uno sforzo abbastanza ridotto, e questo è quanto oggi molti team faranno: "Abbiamo parallelizzato le parti davvero ovvie dell'app" - va bene in alcuni casi. il beneficio derivante dall'assunzione di frutti a bassa pendenza e dall'utilizzo della semplice parallelizzazione sarà proporzionato al numero di core? spesso, quando ci sono da due a quattro core logici, ma non così spesso oltre. in molti casi, questo è un rendimento accettabile, dato il tempo investito. questo modello parallelo è l'introduzione di molte persone all'implementazione di buoni usi del parallelismo.
ciò che impari usando questi banali modelli paralleli non sarà l'ideale in tutti gli scenari paralleli complessi; l'applicazione efficace di progetti paralleli complessi richiede una comprensione e un approccio molto diversi. questi semplici modelli sono spesso staccati o hanno una banale interazione con altri componenti del sistema. inoltre, molte implementazioni di questi banali modelli non si adattano bene a sistemi paralleli effettivamente complessi - una cattiva progettazione parallela complessa può impiegare tanto tempo per essere eseguita come il modello semplice. ill: esegue due volte più velocemente del modello a thread singolo, mentre utilizza 8 core logici durante l'esecuzione. gli esempi più comuni stanno usando / creando troppi thread e alti livelli di interferenza di sincronizzazione. in generale, questo è chiamato rallentamento parallelo. è abbastanza facile incontrarsi se si affrontano tutti i problemi paralleli come semplici problemi.
quindi, supponiamo che dovresti davvero utilizzare un multithreading efficiente nei tuoi programmi (la minoranza, nel clima di oggi): dovrai utilizzare il modello semplice in modo efficace per apprendere il modello complesso e quindi riapprendere come approcci il flusso e l'interazione del programma. il modello complesso è il punto in cui dovrebbe trovarsi il tuo programma poiché è lì che si trova l'hardware oggi e dove verranno apportati i miglioramenti più importanti.
l'esecuzione di modelli semplici può essere immaginata come una forcella e i modelli complessi funzionano come un ecosistema complesso. penso che la comprensione di modelli semplici, inclusi il blocco generale e il threading, dovrebbe essere o sarà presto prevista dagli sviluppatori intermedi quando il dominio (in cui si sviluppa) lo utilizza. comprendere modelli complessi è ancora un po 'insolito oggi (nella maggior parte dei domini), ma penso che la domanda aumenterà abbastanza rapidamente. come sviluppatori, molti più dei nostri programmi dovrebbero supportare questi modelli e la maggior parte dell'uso è molto indietro nella comprensione e nell'implementazione di questi concetti. poiché il conteggio dei processori logici è una delle aree più importanti per il miglioramento dell'hardware, la domanda di persone che comprendono e possono implementare sistemi complessi aumenterà sicuramente.
infine, ci sono molte persone che pensano che la soluzione sia semplicemente "aggiungere parallelizzazione". spesso è meglio velocizzare l'implementazione esistente. è molto più semplice e molto più semplice in molti casi. molti programmi in natura non sono mai stati ottimizzati; alcune persone hanno appena avuto l'impressione che un giorno la versione non ottimizzata sarebbe stata eclissata dall'hardware. migliorare la progettazione o gli algoritmi dei programmi esistenti è anche un'abilità importante se le prestazioni sono importanti: lanciare più core ai problemi non è necessariamente la soluzione migliore o più semplice.
quando si prendono di mira i PC moderni, la maggior parte di noi che ha bisogno di implementare buoni sistemi paralleli non dovrà andare oltre il multithreading, il blocco, le librerie parallele, la lettura di un libro e molta esperienza nella scrittura e nel collaudo di programmi (fondamentalmente, ristrutturando in modo significativo il modo in cui avvicinarsi alla scrittura di programmi).
Lo facciamo, ma scriviamo software pesanti di calcolo in modo da beneficiare direttamente di più core.
A volte lo scheduler sposta molto i thread tra i core. Se ciò non è accettabile, puoi giocare con l'affinità di base.
Allo stato attuale, la frequenza del processore non aumenterà nel prossimo futuro. Siamo bloccati attorno al segno 3 GHz (senza overclocking). Certamente, per molte applicazioni potrebbe non essere necessario andare oltre il multi-threading di base. Ovviamente se stai creando un'applicazione di interfaccia utente, qualsiasi elaborazione intensiva dovrebbe essere eseguita su un thread in background.
Se stai creando un'applicazione che sta elaborando enormi quantità di dati che devono essere in tempo reale, quindi sì, probabilmente dovresti esaminare la programmazione multi-thread.
Per la programmazione multi-thread scoprirai che otterrai rendimenti decrescenti sulle tue prestazioni; puoi trascorrere ore e migliorare il programma del 15%, quindi trascorrere un'altra settimana e migliorarlo solo di un ulteriore 5%.