Processori e nuovi processi produttivi: una via insidiosa

[xeal]

Già questo ricalca, appunto, il concetto di calcolo distribuito. Ma a questo punto tanto vale rimanere legati al classico, piuttosto che pensare di applicarlo anche per il riordino delle istruzioni o l'allocazione dinamica delle risorse. Infatti, se ci pensi bene, già la circuiteria di OOO degli attuali processori è una delle parti più complesse e critiche di una CPU: un procedimento simile per la distribuzione del carico di lavoro in hardware non oso immaginare cosa potrebbe comportare...

Non mi riferivo alla circuiteria, ma al lavoro che mi pare di aver capito che fanno comunque i compilatori per far giungere al processore del codice già parzialmente ordinato, in modo da avere una buona base di partenza per non perdere troppo tempo nel riordino.

L'estensione potrebbe essere del tipo "devo fare 6 somme indipendenti, più altre operazioni che non influenzano le variabili da sommare, ho a disposizione una cpu con due core e 3 alu per core, quindi raggruppo (durante la compilazione) le somme in due gruppi di istruzioni consecutive, schedulando le altre per un momento successivo, e aggiungo una verifica sulle caratteristiche del processore, così, rilevati i due core, faccio eseguire le sei somme parallelamente con un solo ciclo macchina, sempre che il sistema mi consenta di ottenere il controllo di entrambi i core e che, per motivi contingenti, ciascun core non "decida" di ordinare diversamente il proprio gruppo di istruzioni".

Oppure, cosa in realtà (credo) già fattibile (almeno in parte), uso un linguaggio (con relativo compilatore) che mi consenta, tornando all'esempio dell'immagine da renderizzare, di non dover creare esplicitamente un certo numero di sottoprocessi che elaborino una parte specifica dei dati di partenza, bensì di potermi "limitare" a creare una "unità di lavoro" di base e una o più regole per suddividere il lavoro e ricomporre il risultato (un modello di coordinazione), in modo che il programma risultante riconosca le risorse disponibili e provveda a suddividere il lavoro in maniera opportuna (rispettando le regole imposte). Insomma, rendo il compilatore un po' più intelligente (o anche molto, a seconda di quello che posso fare profiquamente in quel preciso momento "storico") e creo un linguaggio ad hoc per pilotare questa maggiore intelligenza in maniera corretta e con lo sforzo minore possibile; non penso certo di lasciar fare tutto al compilatore, partendo da un sorgente "classico" con struttura sequenziale, per quanto avanzate possano essere le tecniche di IA sfruttabili sarebbe alto il rischio di incasinare tutto (la potenza è nulla senza controllo, ma se puoi controllare con abs, ebd, servosterzo, servofreno, servo_selezionatore_di_autostoppiste_bonazze_da_rimorchiare... è meglio, no?)
Chiaramente tutto riferito ad un futuro (più o meno lontano) in cui ciò si possa fare senza grossi problemi, servirebbero progressi anche notevoli nelle tecniche di IA, condicio sine qua non ha senso niente di quello che ho detto.

Per adesso sono un po' scettico sulle reali capacità di un possibile computer quantistico: mi suona paradossale lo sfruttamento deterministico del lavoro prodotto da macchine non deterministiche

Personalmente sono fiducioso che, risolti i problemi tecnici, un modo si trovi. Se non sbaglio, oggi si potrebbe fare tutto con linguaggi di programmazione logica (tipo prolog o lisp), che in un certo senso sono non deterministici, poichè non seguono una strada univoca, ma valutano diverse strade, interrogando un database o applicando delle regole ai predicati in maniera ricorsiva e con tecniche di branch & bound. Forse con quelle macchine si prediligerà questo stile di programmazione. Staremo a vedere (altra toccatina d'obbligo....)

Ciao

[cdimauro]

Originariamente inviato da xeal
Non mi riferivo alla circuiteria, ma al lavoro che mi pare di aver capito che fanno comunque i compilatori per far giungere al processore del codice già parzialmente ordinato, in modo da avere una buona base di partenza per non perdere troppo tempo nel riordino.

OK, adesso è più chiaro. Questo chiaramente si potrebbe fare, ma non so quanto possa essere efficiente...

L'estensione potrebbe essere del tipo "devo fare 6 somme indipendenti, più altre operazioni che non influenzano le variabili da sommare, ho a disposizione una cpu con due core e 3 alu per core, quindi raggruppo (durante la compilazione) le somme in due gruppi di istruzioni consecutive, schedulando le altre per un momento successivo, e aggiungo una verifica sulle caratteristiche del processore, così, rilevati i due core, faccio eseguire le sei somme parallelamente con un solo ciclo macchina, sempre che il sistema mi consenta di ottenere il controllo di entrambi i core e che, per motivi contingenti, ciascun core non "decida" di ordinare diversamente il proprio gruppo di istruzioni".

Appunto. Ricordi i problemi dell'Itanium: gli manca del tutto l'unità OOO, e le prestazioni sugli interi non è che siano un granché. Il problema è che certe cose è meglio lasciarle decidere alla logica OOO al momento preciso in cui debbono eseguite le istruzioni, valutando tutte le risorse disponibili per portarle al termine in quel preciso momento...

Oppure, cosa in realtà (credo) già fattibile (almeno in parte), uso un linguaggio (con relativo compilatore) che mi consenta, tornando all'esempio dell'immagine da renderizzare, di non dover creare esplicitamente un certo numero di sottoprocessi che elaborino una parte specifica dei dati di partenza, bensì di potermi "limitare" a creare una "unità di lavoro" di base e una o più regole per suddividere il lavoro e ricomporre il risultato (un modello di coordinazione), in modo che il programma risultante riconosca le risorse disponibili e provveda a suddividere il lavoro in maniera opportuna (rispettando le regole imposte).

Se non crei dei sottoprocessi, vuol dire che comunque in hardware devi fornire una logica e relativa interfaccia fra CPU/core che permetta di smistare il lavoro fra le loro risorse. E quindi dei collegamenti MOLTO veloci per poter comunicare fra di loro (stile i famosi Transputer).

Insomma, rendo il compilatore un po' più intelligente (o anche molto, a seconda di quello che posso fare profiquamente in quel preciso momento "storico") e creo un linguaggio ad hoc per pilotare questa maggiore intelligenza in maniera corretta e con lo sforzo minore possibile; non penso certo di lasciar fare tutto al compilatore, partendo da un sorgente "classico" con struttura sequenziale, per quanto avanzate possano essere le tecniche di IA sfruttabili sarebbe alto il rischio di incasinare tutto (la potenza è nulla senza controllo, ma se puoi controllare con abs, ebd, servosterzo, servofreno, servo_selezionatore_di_autostoppiste_bonazze_da_rimorchiare... è meglio, no?)

Probabilmente basterebbe un linguaggio tipo Occam.

Chiaramente tutto riferito ad un futuro (più o meno lontano) in cui ciò si possa fare senza grossi problemi, servirebbero progressi anche notevoli nelle tecniche di IA, condicio sine qua non ha senso niente di quello che ho detto.

Gli sviluppi in questo campo ci sono, ma richiedono notevoli sforzi computazionali: l'intelligenza è una brutta bestia...

Personalmente sono fiducioso che, risolti i problemi tecnici, un modo si trovi.

Il fatto è che per risolverli devi sprecare tante di quelle risorse, che alla fine è più conveniente sfruttare la tecnologia attuale (o magari passare alla luce).
In questi casi la penso in maniera diametralmonte opposta a ciò che pensava Einstein ("Dio non gioca a dadi").

Se non sbaglio, oggi si potrebbe fare tutto con linguaggi di programmazione logica (tipo prolog o lisp), che in un certo senso sono non deterministici,

Soltanto il Prolog diciamo che potrebbe esserlo: il lisp è perfettamente deterministico.

poichè non seguono una strada univoca, ma valutano diverse strade, interrogando un database o applicando delle regole ai predicati in maniera ricorsiva e con tecniche di branch & bound. Forse con quelle macchine si prediligerà questo stile di programmazione.

In effetti il Prolog sembra il linguaggio d'elezione per questo tipo di architetture. Comunque, vedi sopra: io rimango scettico sulle possibilità di sfruttamento della meccanica quantistica per questi scopi...

Staremo a vedere (altra toccatina d'obbligo....)

Ciao

Finiremo per consumarle...

[xeal]

Originariamente inviato da cdimaur
Se non crei dei sottoprocessi, vuol dire che comunque in hardware devi fornire una logica e relativa interfaccia fra CPU/core che permetta di smistare il lavoro fra le loro risorse. E quindi dei collegamenti MOLTO veloci per poter comunicare fra di loro (stile i famosi Transputer).

Non dico di non creare processi, ma di crearne uno di base che possa indifferentemente elaborare tutti i dati, se eseguito su un solo processore, oppure una porzione di essi, replicandosi automaticamente su tutti i processori disponibili, e combinando i risultati parziali (eventualmente rielaborandoli) secondo delle regole che tu hai comunque definito, senza però dover individuare esplicitamente il numero (più conveniente) di processi da creare e i processi che dovranno completare l'elaborazione. Il compilatore provvederà a creare una porzione di codice di controllo che riconosce il numero di processori e replica il processo di base suddividendo la mole di dati da elaborare tra tutti i processi, oltre che alla parte di codice corrispondente alla tua regola di coordinazione. Esempio banale: devo sommare due matrici. Il processo di base sommerà gli elementi corrispondenti di ciascuna matrice per tutti gli elementi che gli vengono assegnati; la parte di controllo verifica il numero di processori disponibili e determina il numero di elementi (e gli elementi stessi) da assegnare a ciascun processo, che sarà eseguito su ciascun processore; la regola di coordinazione sarà semplicemente "spostare i risultati parziali nella locazione di memoria prevista per quell'elemento nel risultato finale" (è la situazione più ottimistica: posso coordinare il calcolo perchè conosco esattamente il risultato finale, noto come coordination by result). Se il processore è unico, verrà creato un solo processo.

Ovviamente più veloci sono le interconnessioni e migliore sarà il risultato (in termini di tempo). D'altra parte, ero partito dal presupposto che l'applicabilità di queste "teorie" va letta in chiave futuristica, per poterne valutare validità e conseguenze (detta così sembra un po' come volersi fasciare la testa prima di averla rotta... )

Probabilmente basterebbe un linguaggio tipo Occam

Questo non lo conoscevo ancora.

Gli sviluppi in questo campo ci sono, ma richiedono notevoli sforzi computazionali: l'intelligenza è una brutta bestia...

Altro motivo per spostare la prospettiva di questo discorso anche molto avanti nel tempo.


Quanto allo spreco di risorse con sistemi di calcolo non deterministici, ci sarebbe sotto molti punti di vista. In un certo senso sarebbe come risolvere un problema trattando i dati mediante una codifica non ragionevole, che richiede molto più spazio ma contiene in sè il risultato del problema. Sarebbe come sostituire tutti i numeri reali ad una equazione per risolverla, ma se si potesse fare contemporaneamente si giungerebbe molto rapidamente al risultato. Se gli studi su questi sistemi quantistici conducessero ad un modo per farlo, e si riuscisse a produrre ad un costo accettabile la circuiteria necessaria, che per quanto ho capito dovrebbe essere estremamente "sensibile" e poter assumere un numero elevato di stati, praticamente nello stesso istante, non sarebbe poi così male. Ovvio che oggi possiamo solo accontentarci di quello che abbiamo e magari fingere di non vedere i problemi realizzativi e sognare di poter avere un giorno tra le mani una bestia che esegue i tuoi ordini alla perfezione prima che tu abbia finito di impartirli .

Finiremo per consumarle...

Be', allora tocchiamo ferro, almeno quello si può sostituire...

Ciao

[cdimauro]

Originariamente inviato da xeal
[...]Ovviamente più veloci sono le interconnessioni e migliore sarà il risultato (in termini di tempo). D'altra parte, ero partito dal presupposto che l'applicabilità di queste "teorie" va letta in chiave futuristica, per poterne valutare validità e conseguenze (detta così sembra un po' come volersi fasciare la testa prima di averla rotta... )

OK, già quel che hai scritto non comporterebbe l'utilizzo di molte risorse sia hardware sia software. Comunque, dovresti dare un'occhiata ai Transputer e Occam, perché a naso direi che presentano PARECCHIE similarità...

Quanto allo spreco di risorse con sistemi di calcolo non deterministici, ci sarebbe sotto molti punti di vista. In un certo senso sarebbe come risolvere un problema trattando i dati mediante una codifica non ragionevole, che richiede molto più spazio ma contiene in sè il risultato del problema. Sarebbe come sostituire tutti i numeri reali ad una equazione per risolverla, ma se si potesse fare contemporaneamente si giungerebbe molto rapidamente al risultato. Se gli studi su questi sistemi quantistici conducessero ad un modo per farlo, e si riuscisse a produrre ad un costo accettabile la circuiteria necessaria, che per quanto ho capito dovrebbe essere estremamente "sensibile" e poter assumere un numero elevato di stati, praticamente nello stesso istante, non sarebbe poi così male. Ovvio che oggi possiamo solo accontentarci di quello che abbiamo e magari fingere di non vedere i problemi realizzativi e sognare di poter avere un giorno tra le mani una bestia che esegue i tuoi ordini alla perfezione prima che tu abbia finito di impartirli .

Guarda, all'inizio quando sentivo parlare di computer quantistici mi esaltavao; poi ho cominciato a leggere qualcosa sulla meccanica quantistica, e il mio entusiamo si è decisamente ridimensionato. Veramente, mi sembra difficile pensare di sfruttarla per realizzare calcolatori il cui unico limite sarebbe dettato dalla fantasia; mi sembra, appunto, poco realistico.

[xeal]

Ok, farò una bella ricerca sui transputer e occam.
Per il resto, credo che potendo tornare indietro nel tempo e mostrare un desktop replacement a chi lavorava con l'ENIAC (che se non ricordo male, tra l'altro usava per i numeri una codifica ridondante a 10 bit per cifra, a causa dell'elevatissimo rumore elettrico, oltre ad essere enorme e lontano anni luce dai transistor) a qualcuno verrebbe un infarto... Probabilmente oggi siamo anni luce, tecnologicamente e forse anche quanto a conoscenze, dal poter realizzare un computer quantistico, se mai si potrà fare, però fantasticare ed esaltarsi sulle prospettive future, ogni tanto, dai che male non fa

Ciao

[cdimauro]

Posso assicurarti che sono un tipo a cui la fantasia galoppa molto (alcuni miei amici e mia moglie dicono anche troppo ). Qui, magari, mi vedi un po' troppo razionale nell'affrontare i discorsi che si intavolano: deformazione professionale...

OK, documentati su transputer e occam, e vedrai che troverai l'argomento interessante. Se conosci qualcuno che conserva dei vecchi numeri di MC Microcomputer, materiale ne troverai a vagonate: pure la famosa rete ADPNetwork per Amiga realizzata, appunto, con delle schede con transputer per lo scambio dei dati...