È possibile creare un programma a thread singolo per utilizzare più core?

Il titolo dice tutto: c'è un modo per ottenere un programma più vecchio progettato per utilizzare un singolo core della CPU per utilizzare più core della CPU?

Sfortunatamente, un programma legacy scritto per una singola CPU non può essere costretto a usare più core della CPU. L'utilizzo di più core della CPU richiede più thread, che devono comunicare tra loro garantendo al contempo che non si verifichino condizioni di competizione e altri problemi. Non è possibile fare in modo che un'applicazione precedente utilizzi più del core della CPU a meno che non venga riscritta per farlo, e solo se la natura dell'applicazione ne consente il parallelismo.

Qual è il tuo obiettivo con esso? Prestazioni aumentate? Purtroppo le applicazioni progettate per utilizzare solo 1 core non ne utilizzeranno di più. Ecco di cosa parla questo discorso sulle applicazioni "multi-thread".

Esistono almeno tre tecniche per sfruttare più processori in un programma progettato per l'utilizzo di un singolo core. La più semplice di queste tecniche è quella di utilizzare librerie e codice di sistema che utilizza più core o che possono essere eseguiti almeno parzialmente in parallelo con il codice dell'applicazione. La garbage collection è un esempio di funzionalità che può essere parallelizzata e potrebbe essere possibile eseguire in parallelo con l'esecuzione dell'applicazione. Anche senza la gestione automatica della memoria, esiste un potenziale di parallelismo nelle funzioni di deallocazione della memoria perché l'allocatore di memoria potrebbe avere del lavoro da fare oltre a contrassegnare semplicemente la sezione di memoria come disponibile.

Una seconda tecnica è la traduzione binaria. Sebbene ciò possa essere considerato "riscrittura dell'applicazione", viene eseguito dal software e senza accesso al codice sorgente. La produzione di parallelismo a livello di thread sembra non essere stato l'obiettivo principale della maggior parte della ricerca e dello sviluppo utilizzando la traduzione binaria (che spesso riguarda l'esecuzione di codice legacy su un ISA diverso, lo sfruttamento delle estensioni ISA o l'ottimizzazione per una particolare microarchitettura e l'utilizzo di informazioni dinamiche per fornire ottimizzazione guidata dal profilo di qualità), ma il potenziale è evidente.

Una terza tecnica è il multithreading speculativo. Attualmente nessun processore (che io conosca) supporta il multithreading speculativo gestito dall'hardware. Tuttavia, con l'introduzione della memoria transazionale dell'hardware, disporre di un sistema di runtime tale diventa un po 'più pratico perché l'HTM può essere utilizzato per rilevare conflitti nell'uso della memoria. Il multithreading speculativo gestito da software implicherebbe in genere una traduzione binaria, ma la sua natura speculativa giustifica la considerazione di una tecnica separata.

La praticità di queste tecniche è limitata dai costi associati ai sistemi esistenti (incluso il costo della comunicazione tra thread e di thread di generazione), dal limitato parallelismo che possono sfruttare e dal limitato ritorno sull'investimento (applicazioni importanti che possono essere vantaggiose è probabile che il parallelismo venga riscritto, molte applicazioni trarrebbero benefici relativamente scarsi da tali tecniche (soprattutto con limiti di potenza / termici che consentono a un singolo core di funzionare a una frequenza superiore rispetto a più core) e i costi di sviluppo sono significativi. Tuttavia queste tecniche fanno esistere ed è teoricamente possibile utilizzare più core con un'applicazione progettata per utilizzare un singolo nucleo.

No non può essere. Un programma è esplicitamente scritto per utilizzare più core. Non è banale svolgere il lavoro su più core. Richiede le sincronizzazioni di tutti i thread. Come uno lancia la palla, l'altro prende, uno lucida la palla, uno pulisce, uno controlla la palla se contiene una buona quantità d'aria. Ora immagina che ogni personaggio funzioni in un thread indipendentemente l'uno dall'altro. Qualcuno prova a prendere la palla quando non viene lanciata. Oppure qualcuno prova a lucidare la palla quando viene giocata. O due personaggi che cercano di afferrare e lanciare la palla contemporaneamente. Ci sono molti modi per andare in crash. Pertanto, i programmatori devono riprogettare attentamente un'applicazione single core in modo che possa trarre vantaggio da più core.