K8L: nuovi dettagli da AMD

[MenageZero]

Originariamente inviato da Cimmo

si ma continui a non rispondere alla domanda.
Come sono le licenze di Vista rispetto alle varie versioni che sono state presentate?
TUTTE le versioni Vista supportano almeno 4 core?

Lo chiedo perche' non lo so...

ammesso che quanto riportato al seguente indirizzo sia corretto,

http://www.winsupersite.com/showcase...ions_final.asp

vista, nelle varie versioni client, dovrebbe supportare 1 o 2 (a seconda dell'edizione) cpu fisiche (non si dovrebbe proprio porre il problema licenza in quanto se hai nella macchina più cpu di quelle previste dalla edizione installata -ammesso che si installi lo stesso-, semplicemente non le userai; almeno da come espone la cosa quel sito)

per quanto riguarda il numero di core:

"...While all of the Vista product editions support only one or two physical processors, none are limited to the number of processor cores they will support..."

nessun limite quindi, o meglio per forza di cose ci sarà un limite, non credo che vista sia infinitamente scalabile, ma da come è messa la cosa dovrbbe trattarsi non di un limite "commerciale" e cmq > 4 (quad-core imminenti all'uscita di vista)

[coschizza]

Originariamente inviato da MenageZero

ammesso che quanto riportato al seguente indirizzo sia corretto,

confermo che sono corretti, me li ha confermati uno della MS sul newsgroup dei betatester

[Cimmo]

Originariamente inviato da MenageZero

nessun limite quindi, o meglio per forza di cose ci sarà un limite, non credo che vista sia infinitamente scalabile, ma da come è messa la cosa dovrbbe trattarsi non di un limite "commerciale" e cmq > 4 (quad-core imminenti all'uscita di vista)

ah beh direi buono allora.
Cmq se un'applicazione e' BEN sviluppata puo' essere davvero indipendente dal numero di cpu che ci sono ed essere scalabile all'occorrenza, basta far fare tutto cio' che si puo' fare in parallelo ad un thread diverso e poi sara' il SO a gestire lo scheduling...

[cionci]

Originariamente inviato da Cimmo

basta far fare tutto cio' che si puo' fare in parallelo ad un thread diverso e poi sara' il SO a gestire lo scheduling...

Hai detto niente E' una delle più grandi sfide dell'informatica dei prossimi 5-10 anni... La programmazione concorrente è una brutta bestia...almeno con i linguaggi attuali... Speriamo nella nascita di qualche linguaggio concorrente con i controca##i...

[Cimmo]

Originariamente inviato da cionci

Hai detto niente E' una delle più grandi sfide dell'informatica dei prossimi 5-10 anni... La programmazione concorrente è una brutta bestia...almeno con i linguaggi attuali... Speriamo nella nascita di qualche linguaggio concorrente con i controca##i...

beh io qualche progetto con molti thread concorrenti l'ho fatto, tutto sta nel pensare in parallelo e parallelizzare tutto quello che si puo' fare.
Chiaro che + il progetto si complica e + e' difficile, oltre che aumenta esponenzialmente la difficolta' nel trovare dei bug che si presentano solo in determinate occasioni perche' alcuni thread sono andati avanti prima di altri...

[xeal]

Originariamente inviato da Cimmo

beh io qualche progetto con molti thread concorrenti l'ho fatto, tutto sta nel pensare in parallelo e parallelizzare tutto quello che si puo' fare.

Poi magari fai il profiling e ti accorgi che hai parallelizzato quel fatidico 90% del programma che viene eseguito nel 10% del tempo, che i calcoli pesanti sono rimasti in un thread solo (che non scala per niente) e che gli altri magari, per via degli switch e della sincronizzazione vanno più lenti di prima (e il danno è poco) e vanno anche a rompere le scatole (magari perchè hai anche sbagliato la scelta delle priorità) al thread pesante o a thread/processi di altri programmi (e il danno può essere poco anche qui, ma rimane seccante se il presupposto di partenza era l'ottimizzazione e la scalabilità). Magari non era neanche una cosa tanto facile riuscire a parallelizzare bene, c'è voluto tempo per trovare il modo giusto e per fare un buon debug, e ti cade qualcosa... (il morale sotto le scarpe, che hai capito )...

Naturalmente io sto estremizzando, ma in generale non è banale riuscire a parallelizzare e far scalare l'applicazione (per questo potrebbe essere utile o almeno possibile creare dinamicamente un numero di thread dipendente dal numero di cpu disponibili, almeno finchè numero_cpu <= numero_max_thread_possibili, possibilmente con un'architettura master-warker/a lavagna per le operazioni simili), a meno di ricadere in uno di quei casi super-ultra-mega- noti/studiati/ottimizzati. Per questo vedo di buon'occhio sia tutto l'aiuto possibile da parte del linguaggio e del compilatore (per quanto possibile), come auspica cionci, sia l'evouluzione dell'unità per il calcolo fuori ordine allo studio da parte di amd e intel, che dovrebbe consentire di sfruttare le unità non sfruttate di altri core per massimizzare il parallelismo (si parlava di hyper threading al contrario), ma io estremizzerei il concetto (anche se potrebbe essere complicato e costoso in termini di circuiteria da implementare, per cui il gioco potrebbe non valere la candela) e cercherei di sfruttare anche le unità in virgola mobile non sfruttate nello stesso core, ad esempio convertendo automaticamente le operazioni su interi in operazioni floating point e/o dandole in pasto (ove possibile) alle unità SSEx/MMX sottoforma di vettori (sfruttando, sempre se possibile, le istruzioni su vettori di interi), bilanciando il tutto con un rapporto n/m tra le operazioni accodate nelle pipeline intere (n) e quelle accodate alla fpu (m), in modo che t_esecuzione(m) <= t_esecuzione(n + 1) (e questa è la parte complicata, poichè i tempi di esecuzione inevitabilmente variano da operazione a operazione; in prima istanza si potrebbe pensare di inviare alla fpu le m operazioni che questa è in grado di svolgere più rapidamente tra quelle disponibili - ma tra le rimanenti alcune potrebbero essere accorpate in un'operazione vettoriale - e scegliere come (n+1)esima operazione quella del "pacchetto" m che l'alu impiegherebbe più tempo a svolgere). Naturalmente, un simile bilanciamento impiegherebbe del tempo e potrebbe essere poco "scalabile", specialmente se implementato - in tutto o in parte - con del microcodice, quindi del tutto inutile, anche se, volendo, si potrebbe implementare un qualche algoritmo greedy, ad esempio si potrebbe considerare come tempo di esecuzione per tutte le operazioni alu/fpu/sse il loro (rispettivo) tempo medio, quindi accodarle inizialmente solo sull'alu finchè la somma dei tempi così calcolati per le n operazioni + 1 non diventa maggiore del tempo di esecuzione di una operazione fpu/sse (comprensiva di "casting" all' "andata" e al "ritorno" ), e non creare vettori, o crearli solo se si incontra un numero di operazioni uguali su dati diversi maggiori del numero di alu disponibili oppure si è raggiunto il numero minimo di operazioni in coda per chiamare in causa l'fpu ottenendo un beneficio (sempre che, in ogni caso, non si debba procedere ad un riordino per accorpare operazioni non "vicine" tra di loro che vanifichi tutto introducendo una latenza eccessiva). Inoltre tutto questo ha senso se si ha a disposizione un numero elevato di operazioni indipendenti, anche se si potrebbe provare ad aumentarlo eseguendo operazioni non indipendenti, ad esempio istruzioni in cui uno degli operandi dipende da un'altra operazione, ma con valori in un range definito e piccolo, possibilmente noti - in questo potrebbe essere d'aiuto/necessario il compilatore/un set di istruzioni specifico e il "supporto" da parte del programmatore - oppure da un'operazione booleana - probabilmente in questo caso sarebbe efficace solo nel caso in cui vengano eseguite più operazioni - per poi scegliere il/i risultato/i (e il ramo d'esecuzione) giusto/i (mi pare che itanium consenta qualcosa del genere, però in quel caso tutto è demandato al compilatore, qui l'approccio sarebbe radicalmente opposto); comunque, sarebbe tutto molto complicato... Certo, avendo a disposizione un computer quantistico...

[MenageZero]

Originariamente inviato da Cimmo

ah beh direi buono allora.
Cmq se un'applicazione e' BEN sviluppata puo' essere davvero indipendente dal numero di cpu che ci sono ed essere scalabile all'occorrenza, basta far fare tutto cio' che si puo' fare in parallelo ad un thread diverso e poi sara' il SO a gestire lo scheduling...

si non c'è dubbio, la teoria è quella... solo che anche lo scheduler comprensivo di s.o. intorno bisogna scriverlo... e appunto si parlava innanzitutto di s.o., che neanche è tra la tipologia di progetti più smplici...

non credo che ci sia un s.o. che non abbia un num. max di thread smp possibili e un conseguente numero max di cpu/core (poi dipende anche dalle architetture hw) sfruttabili (ma potrei sempre sbagliare eh, non è che abbia fatto esaustive ricerche appena prima di scrivere queste righe )

non so se in vista(client) il num max di core usabili (che non sappiamo quant'è, se 8, = 2 quadcore, se più, meno credo improbabile ) sarà uguale al max delle "capacità" dell'o.s. o più limitato per scelta, sicuramente il limte a 2 cpu fisiche non è dato da motivi tecnici dato che già xp(server) permette di sfrutttare decine di cpu (ma anche il 2000, nt non ricordo)

[MenageZero]

Originariamente inviato da xeal

Poi magari fai il profiling e ti accorgi che hai parallelizzato quel fatidico 90% del programma che viene eseguito nel 10% del tempo, che i calcoli pesanti sono rimasti in un thread solo (che non scala per niente) e che gli altri magari, per via degli switch e della sincronizzazione vanno più lenti di prima (e il danno è poco) e vanno anche a rompere le scatole (magari perchè hai anche sbagliato la scelta delle priorità) al thread pesante o a thread/processi di altri programmi (e il danno può essere poco anche qui, ma rimane seccante se il presupposto di partenza era l'ottimizzazione e la scalabilità). Magari non era neanche una cosa tanto facile riuscire a parallelizzare bene, c'è voluto tempo per trovare il modo giusto e per fare un buon debug, e ti cade qualcosa... (il morale sotto le scarpe, che hai capito )...

passa all'unieuro, magari hanno unpo' di ottimismo in offerta speciale...
cmq, ottima applicazione la tua delle leggi di murphy e corollari allla programmazione concorrente

Originariamente inviato da xeal

... Certo, avendo a disposizione un computer quantistico...

Se e quando avremo computer quantistici, magari ci metteremo un "attimo"(rispetto al tempo necessitato per averli) a trovare qualcosa per tenerli occupati al 100% e dover tornare subito alla paralellizzazione ed ottimizzazione software...

[xeal]

Il vantaggio dei computer quantistici dovrebbe essere la estrema facilità nella parallelizzazione (in pratica fanno tutto da soli): per sfruttarli (in senso positivo) potrebbe "bastare" programmarli con un linguaggio simile al prolog ed eseguire il backtraking in parallelo (sostanzialmente eseguendo tutte le istruzioni contemporaneamente con tutti i valori possibili per gli operandi non noti e scartando i risultati non validi appena diventano noti). Come impallarli? Vediamo se Murphy mi aiuta... ah, ecco: con una macchina simile potrebbe diventare una bazzecola condurre con successo un'attacco di tipo brute force o ricavare la parte privata di una chiave asimmetrica, quindi una trasmissione sicura richiederebbe l'utilizzo di chiavi sempre più grandi, con continui handshake per cambiarle, da effettuare in forma criptata, e criptando i dati non solo con l'ultima chiave, ma anche con n delle precedenti, in modo tale che un attacker messosi in ascolto in un istante x successivo ai primi n handshake non potrebbe risalire facilmente alle chiavi usate, perchè non le conosce, essendo i dati già criptati - suppongo in particolare che non si usi mai crittografia simmetrica - ma anche se si mettesse in ascolto dall'inizio si potrebbero scambiare da subito delle chiavi in numero sufficientemente grande (e sostituite in un successivo handshake ravvicinato) da rendere probabile che il tempo necessario a crakkarne una (alcune) sia sufficientemente alto affinchè le successive non siano più note all'attacker, il quale dovrebbe prima ricostruire la parte pubblica di ciascuna per risalire a quella privata (presumibilmente, non avendo informazioni utili, mediante brute force, provando una infinità di combinazioni possibili, cosa che potrebbe, con n sufficientemente grande e chiavi con mooooooolti bit, richiedere un tempo non compatibile nè con la durata della transazione, ne, ottimisticamente, con la vita dell'attacker - nel caso in cui avesse interesse a decrittografare i dati scambiati anche a transazione avvenuta); insomma, ogni connessione sicura potrebbe compartare n operazioni di crittografia con chiavi immense ed n tendente ad infinito, per ciascun pacchetto ricevuto e inviato... Dici che ci sono riuscito?

[cionci]

Originariamente inviato da MenageZero

passa all'unieuro, magari hanno unpo' di ottimismo in offerta speciale...
cmq, ottima applicazione la tua delle leggi di murphy e corollari allla programmazione concorrente

Non è una situazione a la Murphy... E' priorio la realtà... Sono rare le applicazione che ci possiamo trovare di fronte ogni giorno che sono parallelizzabili...

Principalmente ci sono quelle che sfruttano il modello thread principale - worker threads in cui il thread principale "raccoglie" dati da fornire a pacchetti ai worker thread... Quelle le sa parallelizzare anche un mulo...

Ma anche qui, metti di avere un solo pacchetto da fornire al worker thread... Praticamente hai il thread principale che è in sleep in attesa di pacchetti...e il worker thread che lavora... Che parallelismo hai ottenuto ? Nessuno...

In molti dei restanti casi ci sono dipendenze troppo strette per parallelizzare efficientemente...

IMHO la soluzione di AMD di sfruttare diversi core con lo stesso thread sarebbe davvero la panacea per i programmatori...ma secondo me si parla ancora di qualche anno...

[MenageZero]

Originariamente inviato da xeal

Il vantaggio dei computer quantistici dovrebbe essere la estrema facilità nella parallelizzazione (in pratica fanno tutto da soli)...

sui computer quantistici sono completamente ignorante, avevo inteso il tuo riferimento solo come salto prestazionale di ordini di grandezza dovuto al mezzo fisico "più veloce"... sorry

[MenageZero]

Originariamente inviato da cionci

Non è una situazione a la Murphy... E' priorio la realtà... Sono rare le applicazione che ci possiamo trovare di fronte ogni giorno che sono parallelizzabili...

lo so (anche per eseprienza diretta purtroppo)..., volevo solo scherzare, prima
(comunque non è colpa mia, è il multithreading ad avere qualcosa contro di me )

Originariamente inviato da cionci

IMHO la soluzione di AMD di sfruttare diversi core con lo stesso thread sarebbe davvero la panacea per i programmatori...ma secondo me si parla ancora di qualche anno...

al riguardo ho letto solo una news qui su hwupg, ma mi sono sempre chiesto: se il singolo thread è (+/- che sia) parallelizzabile, la cpu riuscirà a fare quello praticamente quello che prima era comptenza dei programmatori ?

[cionci]

Le strade sicuramente sono due: aggiungere istruzioni...ed in quel caso dovrebbe essere il compilatore a "guidare" la scheduler intenro alla CPU nello smistare le istruzioni fra i vari core... O lavorare al livello di CPU estraendo le unità di fetch e decode dai vari core e facendone una in comune... A questo punto avremmo già quelle che vengono chiamate da AMD MacroOPS... In tal caso ci potrebbe essere un ulteriore livello della pipeline che "mescoli" le istruzioni (questo già avviene, ma a livello delle sole unità interne ad ogni core per la out-of-order execution) analizzandonone le dipendenze... In questo modo sarebbe possibile organizzare le istruzioni indipendenti in gruppi, ogni gruppo dipendende da una determinata istruzione di un altro gruppo... Fino a quando l'esecuzione di quella determinata istruzione non è terminata il gruppo non può essere instradato verso le unità di esecuzione... Quando un gruppo viene mandato in esecuzione viene allocato parallelamente su tutte le unità disponibili fra i 4 (o N) core...
A questo punto, come avevo detto tempo fa, si risolverebbero alla base anche i salti condizionati... Infatti forse converrebbe eseguire entrambi i branch del salto...
La gestione di questo tipo di approccio è molto complessa e necessiterà sicuramente anche di un register file molto più grande...

[MenageZero]

Originariamente inviato da cionci

Le strade sicuramente sono due: aggiungere istruzioni...ed in quel caso dovrebbe essere il compilatore a "guidare" la scheduler intenro alla CPU nello smistare le istruzioni fra i vari core... O lavorare al livello di CPU estraendo le unità di fetch e decode dai vari core e facendone una in comune... A questo punto avremmo già quelle che vengono chiamate da AMD MacroOPS... In tal caso ci potrebbe essere un ulteriore livello della pipeline che "mescoli" le istruzioni (questo già avviene, ma a livello delle sole unità interne ad ogni core per la out-of-order execution) analizzandonone le dipendenze... In questo modo sarebbe possibile organizzare le istruzioni indipendenti in gruppi, ogni gruppo dipendende da una determinata istruzione di un altro gruppo... Fino a quando l'esecuzione di quella determinata istruzione non è terminata il gruppo non può essere instradato verso le unità di esecuzione... Quando un gruppo viene mandato in esecuzione viene allocato parallelamente su tutte le unità disponibili fra i 4 (o N) core...
A questo punto, come avevo detto tempo fa, si risolverebbero alla base anche i salti condizionati... Infatti forse converrebbe eseguire entrambi i branch del salto...
La gestione di questo tipo di approccio è molto complessa e necessiterà sicuramente anche di un register file molto più grande...

non ho ben afferrato la prima ipotesi(aggiunta di istruzioni e compilatore che fa lo scheduling), ma direi molto, molto interessante la seconda (nonché sinteticamente ma ben spiegata, grazie), in particolare il fetch/decode "esterno" e comune con i core =solo execute (un tale approccio potrebbe il futuro facilitare, tra l'altro, la scalabilità in numero di core per cpu ?) e il raggruppamento istruzioni...
si sa che sono queste le idee che amd sta implementando o è una tua "speculazione" ? (speculazione in senso positivo, imho in tal caso dovresti cercare lavoro presso qualcuno che progetta cpu, se già non sei nel settore... )
e intel(o altri), si sa se sta lavorando a qaulcosa di analogo ?

[Cimmo]

Originariamente inviato da cionci

Le strade sicuramente sono due: aggiungere istruzioni...ed in quel caso dovrebbe essere il compilatore a "guidare" la scheduler intenro alla CPU nello smistare le istruzioni fra i vari core... O lavorare al livello di CPU estraendo le unità di fetch e decode dai vari core e facendone una in comune... A questo punto avremmo già quelle che vengono chiamate da AMD MacroOPS... In tal caso ci potrebbe essere un ulteriore livello della pipeline che "mescoli" le istruzioni (questo già avviene, ma a livello delle sole unità interne ad ogni core per la out-of-order execution) analizzandonone le dipendenze... In questo modo sarebbe possibile organizzare le istruzioni indipendenti in gruppi, ogni gruppo dipendende da una determinata istruzione di un altro gruppo... Fino a quando l'esecuzione di quella determinata istruzione non è terminata il gruppo non può essere instradato verso le unità di esecuzione... Quando un gruppo viene mandato in esecuzione viene allocato parallelamente su tutte le unità disponibili fra i 4 (o N) core...
A questo punto, come avevo detto tempo fa, si risolverebbero alla base anche i salti condizionati... Infatti forse converrebbe eseguire entrambi i branch del salto...
La gestione di questo tipo di approccio è molto complessa e necessiterà sicuramente anche di un register file molto più grande...

si certo cio' che avevo sviluppato io era un sistema client-server che trasmetteva dati di grosse quantita' spezzandoli in tante parti.
Ogni client e ogni server lavorava in un thread per i cavoli suoi e tutto funzionava a meraviglia, chiaro che ci sono situazioni dove parallelizzare e' difficile, perche' dipendi da calcoli precedenti e quindi un approccio di questo tipo sarebbe davvero una manna dal cielo.

[cionci]

Sono speculazioni ovviamente...

Comunque ti spiego meglio l'aggiunta di istruzioni come potrebbe funzionare: metti che esistano due istruzioni per definire l'inzio e la fine di una sezione di codice parallelizzabile...e da quali registri queste istruzioni dipendono..

Il compilatore in un primo passo genererebbe il codice così come avviene adesso... In un secondo passo potrebbe fare un'analisi delle dipendenze e creare questi gruppi di istruzioni indipendenti fra loro e dipendenti da un certo numero di registri (numero che andrebbe limitato in base a prove pratiche)...

Si tratta a questo punto di creare nella CPU una unità che divida il gruppo di istruzioni fra i vari core e analizzi queste nuove istruzioni per creare le dipendenze rispetto ai vari registri... Queste saranno vincoli aggiuntivi per l'out-of-order execution... L'unica cosa è che i vari core dovrebbero comunque condividere il register file...

Riguardo alla seconda ipotesi, che secondo me è quella più valida e affascinante (mi sembra che AMD abbia già diversi brevetti per un multicore con fetch, decode e cache comuni), mi venne in mente quando Intel parlò di voler integrare fino a 100 core nella stessa CPU... Consentirebbe appunto di scalare molto bene e di semplificare ogni core... Di fatto il 30% (esclusa la cache) di ogni CPU è oggi occupato dall'unità di fetch e decode... Farne una, anche più complicata (perchè il numero di istruzioni che deve "sputare" fuori sarebbe nettamente maggiore) per tutti i core, sicuramente occuperebbe meno spazio di quello che occupa ora...
Sinceramente non vedo altre strade tecnicamente possibili rispetto a quella che ho supposto... Altrimenti ci sarebbero veramente troppe dipendenze fra i vari core per utilizzare qualsiasi altro approccio che mi viene in mente...