Il multithreading deve essere utilizzato per attività che non implicano operazioni IO?

Uno dei motivi principali per l'utilizzo dei thread anche in un processo completamente legato alla CPU è consentire l'interazione o l'aggiornamento dell'output di avanzamento tramite un'interfaccia utente di qualche tipo. Mentre eseguire il calcolo in primo piano senza consentire l'interazione sarebbe più efficiente, il leggero costo di passaggio e gestione degli eventi dell'interfaccia utente di solito supera la penalità di costringere un utente ad attendere indefinitamente per un processo.

Un altro caso in cui eseguire più thread su un singolo core sarebbe più efficiente quando un processo a più stadi coinvolge uno stadio che produce molti risultati temporanei che vengono elaborati in una fase successiva. L'esecuzione di queste fasi in serie potrebbe esaurire la memoria disponibile. Eseguendoli in parallelo consente al secondo stadio di liberare memoria mentre elabora i risultati.

Infine, aggiungendo più cache alle nostre architetture, i thread possono spesso diventare inattivi quando si verifica un errore di cache durante l'accesso alla memoria. Questo dà un po 'di tempo perché un altro thread si attivi e faccia un po' di lavoro.

I principali vantaggi del multi-threading rispetto alla multielaborazione includono

• memoria condivisa
• meno overhead per il cambio di contesto
• astrazione più semplice

La maggior parte dei sistemi operativi moderni fornisce anche un metodo per condividere la memoria tra i processi. Anche in questo caso, consentire al sistema operativo o alla macchina virtuale di spostare i thread su più processori quando disponibili è molto allettante. Ad esempio, quando sposti un programma Java a più thread da un computer single-core a uno con più core, la JVM utilizzerà automaticamente questi altri core.

Sembra che ci siano alcuni malintesi sotto la tua domanda.

• Sebbene sia possibile avere un'architettura in cui ogni CPU ha una propria memoria dedicata, questo non è il caso dei processori multi-core. Potresti incontrare una simile architettura quando lavori con super-computer o cluster di calcolo.
  In un processore multi-core, ogni core ha una propria cache, ma la maggior parte della memoria (tutta la RAM) è condivisa tra i core. Ciò significa che è possibile eseguire contemporaneamente due thread dello stesso processo (applicazione) su diversi core.
• Non è la CPU che seleziona un'attività da eseguire, ma è (lo schedulatore nel) il sistema operativo che seleziona le attività da eseguire su ciascuna CPU. In questa selezione, verranno prese in considerazione solo le attività in cui il sistema operativo sa che l'attività può fare dei progressi. Le attività che attendono qualcosa (un'operazione di IO da completare, un blocco da rilasciare, ecc.) Non saranno prese in considerazione per la pianificazione finché il sistema operativo non sarà a conoscenza che la condizione è stata soddisfatta.

Per rispondere alle tue domande:

1. Di solito si consiglia di avere un thread separato per l'interazione dell'utente che non esegue calcoli a lungo termine o che potenzialmente blocca l'I / O, poiché ciò migliora la reattività percepita dell'applicazione.
   Potrebbe anche essere utile avere più thread che eseguono calcoli, perché potrebbero essere eseguiti su core differenti (se ci sono più core disponibili) e può semplificare la progettazione dell'applicazione, il che è un vantaggio anche se si ha solo un CPU singola.
2. Il multi-threading è spesso preferito rispetto al multi-processo, perché la comunicazione tra thread è spesso più facile da comprendere / specificare rispetto alla comunicazione tra processi, perché i thread condividono la stessa memoria. Inoltre, a seconda dell'implementazione del thread nel sistema operativo, il passaggio delle attività tra i thread può essere più efficiente del passaggio delle attività tra i processi.

Ci sono diversi motivi per cui le persone hanno iniziato a usare thread oltre a fare I / O. Uno dei motivi è che è presumibilmente più facile da programmare se si è abituati a un mondo a thread singolo. Lavorare con un sacco di I / O in un singolo processo nei vecchi tempi significherebbe creare macchine di stato molto elaborate che erano difficili da debellare e comprendere. Inoltre, se si esegue una macchina a stati di questo tipo, è necessario suddividere i calcoli in piccoli pezzi poiché un lungo calcolo può rendere la propria applicazione non rispondente. Il vecchio Netscape Navigator è stato fatto in questo modo.

I thread diversi solitamente possono utilizzare core diversi, quindi se si hanno operazioni legate alla CPU senza molto I / O, queste operazioni possono essere eseguite in un core diverso senza bloccare il resto dell'applicazione. È l'opposto di quello che hai detto, quindi penso che quello che stai pensando di thread è ciò che in alcuni punti è chiamato thread verde, cioè thread che non sono programmati dal sistema operativo. Un pezzo di codice viene eseguito fino a quando non dà il controllo, cioè esegue I / O o rese.

Ora, ci sono diversi motivi per cui le persone a volte preferiscono il multithreading alla multielaborazione. I processi di solito non condividono la memoria, quindi non sono possibili molti stili di programmazione. Invece di aggiornare una struttura dati in memoria devi inviare un messaggio a un altro processo e l'altro processo deve interpretarlo. È così che molte lingue funzionano oggi e sono perfette per molte cose, ma è uno stile di programmazione diverso. Un'altra ragione è che i processi sono in genere più pesanti e richiedono più risorse rispetto ai thread. Puoi avere la tua applicazione con centinaia di thread, ma di solito non puoi avere centinaia di processi.

Quando si tratta di comprendere l'elaborazione parallela (ho intenzione di usare questo termine come termine generico), è meglio iniziare con le basi. Prendilo in modo lento e semplice all'inizio.

Sono a conoscenza del fatto che thread e processi sono più o meno gli stessi, ma i thread sono un sistema di lavoro leggero mentre i processi sono pesanti. Questi sono i termini utilizzati per indicare la quantità di lavoro del sistema che deve essere generato per supportare questi accordi di lavoro. Questa è una questione importante perché l'elaborazione parallela causa al computer un po 'di lavoro extra. Se un'attività genera un numero elevato di thread, questo è più efficiente rispetto a quando deve generare un numero uguale di processi per fare lo stesso lavoro.

Cerca di capire l'I / O nel senso più ampio possibile. Non si tratta solo di input dell'utente, o I / O su dispositivi di archiviazione di massa (disco). Dal punto di vista della CPU, una lettura dalla memoria principale è I / O. Una lettura cache è anch'essa di I / O, anche la più veloce cache di livello 1. L'elaborazione parallela consente di continuare il lavoro produttivo anche se un thread (o processo) è in attesa di I / O, poiché altri thread non bloccati possono continuare ad essere eseguiti.

E non rimanere mai bloccato pensando di conoscere o controllare l'ordine di esecuzione dei thread che si generano! Mentre è possibile forzare la sincronizzazione delle attività parallele, farlo solo se la logica del problema lo richiede. La sincronizzazione rallenta il ritmo di esecuzione del programma e non è buona se non strettamente necessario.

La maggior parte delle CPU moderne sono animali complessi internamente e abbattere persino le istruzioni di linguaggio Assembly in micro-istruzioni.

Tutti i discorsi su CPU multiple rispetto a core che utilizzano CPU sono solo elementi di implementazione hardware. Anche una singola CPU, non basata su core, può spesso fare un uso molto efficace del software parallelo. Richiede solo il supporto del sistema operativo e delle applicazioni.

La rozza gerarchia della potenza del processore (in ordine crescente di potenza di esecuzione delle istruzioni) è:

1. CPU singola, no multi-core
2. CPU multipla, no multi-core
3. CPU singola, multi-core
4. CPU multipla, multi-core

Perché? Le CPU multi-core possono indirizzare le attività intorno ai core interni molto più rapidamente di quanto impieghi per inviare un'attività a una CPU diversa. Inoltre, le CPU multi-core condividono abitualmente i livelli di cache, più delle CPU single-core. Ciò consente anche una più rapida condivisione dei dati.

Le metriche rozze che ho visto dicono che l'invio di un compito da un core ad un altro, all'interno di una singola CPU è approssimativamente 10 volte più veloce di dover inviare quell'attività da off-chip a un'altra CPU.

Si noti anche che le architetture a zero condiviso, come i supercomputer di routine, lo rendono ancora più astratto. Poi hai più interi computer che lavorano insieme come un'unità coordinata. La potenza di elaborazione delle istruzioni aumenta, così come il sovraccarico delle comunicazioni tra processi (IPC). Questo è direttamente analogo all'aumento di potenza con overhead IPC attendant rilevato tra più CPU single-core e una CPU multi-core. Tutto trovato all'interno di un singolo computer con un singolo sistema operativo.

Ecco alcune linee guida generali per la programmazione dell'elaborazione parallela:

• implementa tutte le attività parallele possibili, come consentito dalla logica;
• stai lontano dal tentativo di coordinare il numero di sottoattività che devi generare in correlazione con il tuo attuale design della CPU;
• evita di indovinare le capacità di elaborazione delle istruzioni della CPU;
• evita la sincronizzazione dei processi, ove possibile;

In effetti è un buon modello di design non progettare il tuo hardware attuale, il più possibile. Il software può avere una durata molto lunga mentre l'hardware ha una durata di vita relativamente breve e fissa. Quindi scommetti su (spendendo più tempo) sul software più che sull'hardware. L'hardware cambierà, puoi contare su di esso.