Chi ha detto che è impossibile? Estremamente impegnativo. Non necessariamente fornendo i benefici che vi aspettate. Proibitivamente costoso. Ma impossibile. No, non è impossibile.
Si potrebbe fare con una singola applicazione software? Sì, se si è disposti a spendere qualcosa dell'ordine di un miliardo di dollari per costruire una tale app e probabilmente aspettare cinque anni per renderla utilizzabile e probabilmente sarebbe ancora buggata e capricciosa.
È già abbastanza difficile per gli umani scrivere app multithreaded. Automatizzare il processo è molto più difficile.
Lasciatemi fare un esempio concreto. Uno dei miei ultimi compiti alla Intel è stato convertire una parte di questo strumento di espressione regolare chiamato Hyperscan per fare alcune cose in multithreading. Ora le espressioni regolari sono un tipo di programma abbastanza conosciuto e contenuto. Puoi scrivere un semplice interprete di espressioni regolari come studente universitario. Uno veramente semplice potrebbe anche essere semplicemente un compito a casa.
Inoltre, la teoria è ben stabilita e una parte di hyperscan ha convertito le NFA in DFA usando l'algoritmo standard. Ma le DFA sono a thread singolo e soffrono di esplosione combinatoria. Quindi, hyperscan ha strategie di backup se la conversione non funziona, come eseguire una NFA. Ma l'esecuzione di un DFA è più efficiente quando la conversione funziona. Quindi, il mio compito era quello di trasformare l'NFA in più DFA (fino ad un massimo di otto) e poi provare ad eseguire queste DFA in parallelo.
Step 1, ho riscritto il motore DFA in modo che se si verificava un'esplosione combinatoria, smetteva di costruire la DFA corrente e passava a costruirne una nuova. Rinunciando solo se ne aveva già costruiti otto.
Step 2, eseguendo i DFA in parallelo come se fossero thread, ma in lock-step.
Step 3, rielaborando i DFA in modo che fossero interleaved e facessero più lavoro in parallelo possibile.
Ho scritto altrove sul passo 3. Tuttavia, nessuno di questi compiti era del tutto banale e questo nonostante fossero essenzialmente cose da fare da manuale. Il progetto ha richiesto circa sei mesi prima di avere qualcosa che funzionasse abbastanza bene che il risultato fosse migliore della semplice esecuzione dell'NFA originale e valesse la pena di essere spedito. Naturalmente, a quel punto, quando ha funzionato, ci ha fatto ottenere un miglioramento sostanziale delle prestazioni e ci ha fatto vincere il progetto presso il cliente specifico a cui ci stavamo rivolgendo.
Così, qui c'era il multithreading di un'applicazione - non l'intera applicazione, solo una parte specifica di essa, dove la parte che stavamo multithreadando aveva proprietà semplici e piacevoli e si sta ancora parlando di mesi di tempo di una persona che conosce a fondo quell'area di applicazione.
Confrontate questo con la quantità di sforzo che va in cose come emulatori per un chip su un altro. Quei progetti sono pluriennali e composti da più persone. Non stanno facendo alcun multi-threading, stanno solo cercando di assicurare che la semantica di un chip sia fedelmente ricreata su un altro chip. O cose come VMware, che non stanno nemmeno facendo l'intero set di istruzioni, solo un piccolo sottoinsieme, eppure intere compagnie si sono formate intorno all'idea. O compilatori just-in-time per le JVM.
Tutte queste cose sono grandi, e cercare di ristrutturare un programma a thread singolo in un programma multi-thread è altrettanto grande di tutte queste cose.
Non accadrà presto. Certamente non sarà qualcosa quando accadrà che si possono buttare giù 50 dollari e ottenere un acceleratore di gioco.