Link alla notizia: http://www.hwupgrade.it/news/cpu/da-intel-una-nuova-tecnologia-per-il-software-single-threaded_32658.html

Al momento in fase di sviluppo, Anaphase si presenta come una tecnologia capace di portare sensibili miglioramenti a tutte quelle applicazioni single thread insensibili all'incremento del numero di core

Click sul link per visualizzare la notizia.

da parecchio che ne sento parlare, ma ancora non si è visto nulla di concreto..

Reverse HT vi dice nulla

Beh concettualmente mi sembra anche giusto che un produttore leader mondiale di proci venga incontro alle esigenze degli utilizzatori finali di alcuni sw.
Non è che si può sempre scaricare il fardello dell'innovazione tecnologica sulle spalle degli sviluppatori di sw; daltronde se un sw è valido e apprezzato in tutto il mondo, perchè deve essere riscritto per essere ottimizzato su più core?
Considerato anche:
- la possibilità di perdere affidabilità rispetto a prima
- un costo in più da affrontare per l'utente finale
- la compatibilità al 100% di ciò che è stato fatto

Brava Intel

ho studiato un pò di roba sui thread al corso di sistemi di elaborazione. Sono ancora tanto diffusi software single-thread da impegnare intel nello studio di metodi x l'ottimizzazione su sistemi multi core?
ps. Scusate l'ignoranza.

eh, purtroppo mi sa che la mossa sarà più una manovra di mercato per spingere al cambio processore, perché al giorno d'oggi anche i programmi che più sono singlecore (i giochi) iniziano a passare al multicore (esempi, dirt o crysis) e ben pochi potranno trarne vantaggio...

E' una mossa interessante. Molti software, e non solo legacy, sono single-threaded in tutto o in parte.
A questo però Intel dovrebbe affiancare un migliore supporto ad OpenMP, che è una tecnologia validissima tuttora poco sfruttata.
E il motivo è poca dissemination, pochi tutorial e qualche zona grigia di troppo sul fronte prestazionale e della compatibilità (cicli for che a volte misteriosamente rallentano anziché accelerare, problemi di condivisione delle variabili non sempre facili da risolvere etc.).
Con la forza di Intel (ma conviene anche ad AMD), dare una bella mano agli sviluppatori per far adottare OpenMP sarebbe una gran cosa...

E sì qui ci sono giustamente i babbioni che si bevono tutte le stro.....te che dicono, non sanno più che fare quella è la verità.........processori esacore che per una utenza casalinga sono solo uno spreco di soldi e loro li vogliono far passare per necessari.....queste forzature distruggeranno il mercato........purtroppo finchè dettano legge con le vendite c'è poco da fare...........che bello siamo nel 2010 ed il concetto di tecnologia è un qualcosa di quanto mai remoto ancora.......ma vaff...

ci sono tentativi accademici di usare openmp su Quake, ma esattamente come dici si fanno meno fps, quindi il rendering software non ha alcun senso, ok le matrici sono la cosa più parallelizzabile questo mondo.. ma c'è già opengl e le gpu che digeriscono tutto spezzettato.
nei giochi ( per ora ) è un confronto impari.

per fortuna che c'è netcrusher a ricordarci che c'è gente che usa un solo programma alla volta e che per questo non servono processori multicore..

eh si.... importante non far avanzare la tecnologia per 4 persone che non usano il pc come si potrebbe.. e pensare che ho la suocera che usa più applicativi contemporaneamente sul pc.. sono saranno muti-thread.. ma quando hai un quad core e 4-5 programmi aperti scommetto che il sistema operativo li riesce a suddividere sui vari core senza neanche far fatica..

netcrusher.. non so che ci fai tu con il pc.. ma stai facendo discorsi come quelli che facevano 50 anni sull'utilità dei computer.. chi mai vorrebbe un computer in casa ?.. ora molta gente ha un netbook e un pc.. quando non anche un notebook.. e mi vieni a dire che non servono gli esacore ?.. oggi no.. ma domani ?.. io ora ho 13 programmi aperti.. che faccio ?.. ne chiudo qualcuno o posso usare i 4 core del mio i7 ?

Complimenti a Intel, finalmente sfrutteremo al max questi core ancora inutilizzati in tanti e troppi programmi/giochi

...
Non è che si può sempre scaricare il fardello dell'innovazione tecnologica sulle spalle degli sviluppatori di sw; daltronde se un sw è valido e apprezzato in tutto il mondo, perchè deve essere riscritto per essere ottimizzato su più core?
...
Brava Intel

loro si sono già accollati il fardello dell'innovazione HW mettendo anche in commercio tools software che aiutano per lo sviluppo multicore.
Le software house, se vogliono continuare a vendere i loro prodotti, mi sembra giusto che si adeguino anche loro.

ci sono tentativi accademici di usare openmp su Quake, ma esattamente come dici si fanno meno fps, quindi il rendering software non ha alcun senso, ok le matrici sono la cosa più parallelizzabile questo mondo.. ma c'è già opengl e le gpu che digeriscono tutto spezzettato.
nei giochi ( per ora ) è un confronto impari.

Dipende cosa ci vuoi fare con le matrici.
Risolvere un sistema lineare, che è una cosa abbastanza semplice (si insegna a farlo alle superiori), tramite l'algoritmo di gauss, non è parallelizzabile.

Comunque io non mi riferivo all'uso di OpenMP per i giochi (dove gli sviluppatori di motori 3D sanno già come e dove usare il multithreading).
Ci sono molti altri campi dove parallelizzare alcuni calcoli con minimo impatto per il programmatore potrebbe migliorare le prestazioni di alcuni software.
Non sempre una software house ha l'interesse o la convenienza a riscrivere il proprio software in chiave multithread, e qui OpenMP può dare una grossa mano. Bisogna spingerla però, e Intel ha i mezzi per farlo.

Ad occhio e croce è un campo minato..

Se i programmi sono single thread per parallelizzarli e mantenerne la coerenza del flusso di istruzioni si rischia di fare un lavoro che è più oneroso di quanto si ottiene come beneficio.
Immaginate un software monolitico che viene parallelizzato a forza, tra controlli di sincronia e di flusso si caricano gli altri core che invece non verrebbero coinvolti. Insomma per un (ottimistico) miglioramento prestazionale del 40% ho un consumo di corrente (e di risorse) ALMENO doppio...

Certo è un concetto interessante ed aprirebbe degli incrementi prestazionali a software che non vedono miglioramenti tangibili da quando è finita la corsa ai MHZ...

Sono scettico (specialmente per le problematiche di compatibilità ) ma possibilista, vediamo che riescono ad inventarsi.

Credo che l'importante siano le prestazioni, se poi aumentano i consumi pazienza, poi col tempo si riuscirà anche ad ottimizzare la cosa ed a ridurli un po'.

Ad occhio e croce è un campo minato..

Se i programmi sono single thread per parallelizzarli e mantenerne la coerenza del flusso di istruzioni si rischia di fare un lavoro che è più oneroso di quanto si ottiene come beneficio.
Immaginate un software monolitico che viene parallelizzato a forza, tra controlli di sincronia e di flusso si caricano gli altri core che invece non verrebbero coinvolti. Insomma per un (ottimistico) miglioramento prestazionale del 40% ho un consumo di corrente (e di risorse) ALMENO doppio...

Certo è un concetto interessante ed aprirebbe degli incrementi prestazionali a software che non vedono miglioramenti tangibili da quando è finita la corsa ai MHZ...

Sono scettico (specialmente per le problematiche di compatibilità ) ma possibilista, vediamo che riescono ad inventarsi.

Non credo che si abbiano problemi di compatibilità, è proprio questa l'innovazione, il programma viene eseguito comportandosi da Single-threaded quale è, mentre il processore spezzetta quel thread in piu processi gestiti dagli altri core. Ci credete se vi dico che io gia avevo pensato a questa cosa e tra me e me mi sono anche risposto "bha che cazzata starò pensando..figurati poi se le grosse compagnie non l'avevano già fatto" :sofico:

Mi sembra di essere scemo, ma voglio proprio vedere come se la caverà tutta la potenza dell'Intel (che in questo caso non può avvalersi di imbrogli di mercato), per risolvere quei problemi di natura essenzialmente scientifica che hanno pochi parametri in input e che lavorano ore ed ore soltanto in CPU, per ottenere alla fine magari solo un VALORE MUMERICO in output... Questi programmi hanno la squisita caratteristica di avere, istruzione per istruzione, assoluta immutabile sequenzialità, nel senso che ogni riga di codice può essere eseguita solo e soltanto avendo il risultato dell'elaborazione della riga di codice precedente!
Forza Intel, vediamo nella tua immensa presunzione come te la cavi!

[...]
Non è che si può sempre scaricare il fardello dell'innovazione tecnologica sulle spalle degli sviluppatori di sw; daltronde se un sw è valido e apprezzato in tutto il mondo, perchè deve essere riscritto per essere ottimizzato su più core?
[...]

Mhhh... Interessante prospettiva. Perché allora, seguendo questo ragionamento, non è prassi che tutti i software vengano scritti ad 8 bit per poi essere tradotti a 64 bit dalla CPU?

Software e hardware sono i due binari dell'informatica; se non avanza l'uno non basta che l'altro sia anni luce avanti: il treno rimane fermo.

ovviamente sarà un software intel only che gli farà fare bella figura nei bench, casytrando i rivali AMD , vero?? stessa cosa dell ss2 e dei compilatori ad hoc?

ovviamente sarà un software intel only che gli farà fare bella figura nei bench, casytrando i rivali AMD , vero?? stessa cosa dell ss2 e dei compilatori ad hoc?

invece di trollare potevi leggere meglio è avresti notato che la cosa prevede un'unita di logica integrata nella cpu per poter implementare la cosa

nn basta un sw per poter dare in pasto un codice a + core contemporaneamente

come ad esempio il turbo core...

ps sempre per ridere, amd ha le sse2 come le 3 e le 4

ovviamente sarà un software intel only che gli farà fare bella figura nei bench, casytrando i rivali AMD , vero?? stessa cosa dell ss2 e dei compilatori ad hoc?
Guarda che anche amd ha le ss2, e inoltre c'è scritto nella news che I PROCESSORI DOTATI DI QUESTA TECNOLOGIA HANNO AL LORO INTERNO UN'UNITA' A PARTE CHE PROVVEDA INSIEME AL SOFTWARE A DAR SUPPORTO A QUESTA TECNOLOGIA (Scusate il caps, ma certa gente non legge nemmeno se glielo scrivi in size=7 )
Mi sembra di essere scemo, ma voglio proprio vedere come se la caverà tutta la potenza dell'Intel (che in questo caso non può avvalersi di imbrogli di mercato), per risolvere quei problemi di natura essenzialmente scientifica che hanno pochi parametri in input e che lavorano ore ed ore soltanto in CPU, per ottenere alla fine magari solo un VALORE MUMERICO in output... Questi programmi hanno la squisita caratteristica di avere, istruzione per istruzione, assoluta immutabile sequenzialità, nel senso che ogni riga di codice può essere eseguita solo e soltanto avendo il risultato dell'elaborazione della riga di codice precedente!
Forza Intel, vediamo nella tua immensa presunzione come te la cavi!
Ma, tra l'altro, se ami così tanto i software scientifici, mi spieghi perchè GODI che Intel rimanga dietro? Dovresti godere invece che l'azienda x riesca a finire in tempi molto inferiori i calcoli che prima si facevano in ore! Bah, che gente

sono abbastanza scettico, ogni sw non può essere parallelizzato oltre un certo limite indipendentemente dalla tecnologia adottata, ci sono dei lock che devono essere rispettati e un sistema come questo rischia di parallelizzare su due o più core un programma sequenziale non portando alcun beneficio anzi caricando di overhead il sistema per avere 0 incrementi prestazionali,

parallelizzare un sw non è un'operazione banale anche durante la progettazione, figuriamoci a valle della realizzazione del sw.

sistemi come questo possono incrementare le performance di programmi di vecchia concezione progettati senza l'uso di multithread ma ridurrano le performance dei sw già ottimizzati per sfruttare il multithread, un pò come è successo con ht

mi rivolgo agli esperti di progettazione di chip (c'è qualcuno qui su hwup, forse anche !fazz sa darmi delle risposte)
perché non si fa un sistema che il core è unico, formato da tot pipeline etc... come quelli che ci sono adesso, con un'unità che suddivide il lavoro PRECISAMENTE sulle unità necessarie, sfruttando tutta la potenza? che differenza ci sarebbe con un numero multiplo di core?
so che c'è qualche problema che impedirebbe di farlo, altrimenti in decine di anni di evoluzione ci avrebbero pensato...

mi rivolgo agli esperti di progettazione di chip (c'è qualcuno qui su hwup, forse anche !fazz sa darmi delle risposte)
perché non si fa un sistema che il core è unico, formato da tot pipeline etc... come quelli che ci sono adesso, con un'unità che suddivide il lavoro PRECISAMENTE sulle unità necessarie, sfruttando tutta la potenza? che differenza ci sarebbe con un numero multiplo di core?
so che c'è qualche problema che impedirebbe di farlo, altrimenti in decine di anni di evoluzione ci avrebbero pensato...

il problema è che il software non è completamente parallelizzabile, se una parte del codice richiede come input il risultato di un precedente blocco, questi due blocchi non potranno mai essere eseguiti in parallelo.

Inoltre il problema di sfruttare al 100% il processore si ha principalmente perchè il processore è nettamente più veloce delle periferiche di i/o e quindi a volte il programma deve attendere che il disco o qualche altra periferica finisca di operare.

mi rivolgo agli esperti di progettazione di chip (c'è qualcuno qui su hwup, forse anche !fazz sa darmi delle risposte)
perché non si fa un sistema che il core è unico, formato da tot pipeline etc... come quelli che ci sono adesso, con un'unità che suddivide il lavoro PRECISAMENTE sulle unità necessarie, sfruttando tutta la potenza? che differenza ci sarebbe con un numero multiplo di core?
so che c'è qualche problema che impedirebbe di farlo, altrimenti in decine di anni di evoluzione ci avrebbero pensato...

Se non ho capito male l'architettura, il prossimo bulldozer di AMD dovrebbe fare proprio questo. Puoi trovare altre info nel thread dedicato.

edit: volevo aggiungere poi una considerazione. Concettualmente non è impossibile che, avendo a disposizione n core di un processore, tutti concorrono all'esecuzione di un solo thread. Sempre concettualmente è come avere tante unità esecutive sparse fra diversi core. Il problema pratico è però che spostare dati fra i core probabilmente è ben più costoso (in termini di tempo) che farli eseguire da un singolo core, visto che bisogna spargere i dati, tenere le cache coerenti, trasferire dati, eseguirli e poi raccogliere i dati sparsi.

Se non ho capito male l'architettura, il prossimo bulldozer di AMD dovrebbe fare proprio questo. Puoi trovare altre info nel thread dedicato.

edit: volevo aggiungere poi una considerazione. Concettualmente non è impossibile che, avendo a disposizione n core di un processore, tutti concorrono all'esecuzione di un solo thread. Sempre concettualmente è come avere tante unità esecutive sparse fra diversi core. Il problema pratico è però che spostare dati fra i core probabilmente è ben più costoso (in termini di tempo) che farli eseguire da un singolo core, visto che bisogna spargere i dati, tenere le cache coerenti, trasferire dati, eseguirli e poi raccogliere i dati sparsi.
non penso

per come è nata l'architettura delle cpu (ti ricordo che per quanto le cpu nuove siano stravolte devono basarsi su una famiglia vecchiotta di cpu gli x86 appunto) è improbabile se non impossibile che una routine venga eseguita da più core contemporaneamente e nel caso fosse possibile è probabilmente controproduttivo

esempio pensa all'operazione base di una cpu, spostare i file dalla memoria a un registro e viceversa, pensa a 2 operazioni analoghe che vanno svolte in successione e la 2° deve avere il dato dalla prima

nn penso che la seconda possa fare manco un'operazione di fetch dell'istruzione senza quel dato, o nel caso fosse possibile farlo dovrebbe cmq aspettare un'attimo la risposta del secondo dato

questo prevede oltretutto che tutte le istruzioni debbano essere eseguite nello stesso tempo (stessa durata) nn sono sicuro che siano tutte uguali nelle cpu moderne

il problema è che il software non è completamente parallelizzabile, se una parte del codice richiede come input il risultato di un precedente blocco, questi due blocchi non potranno mai essere eseguiti in parallelo.

Inoltre il problema di sfruttare al 100% il processore si ha principalmente perchè il processore è nettamente più veloce delle periferiche di i/o e quindi a volte il programma deve attendere che il disco o qualche altra periferica finisca di operare.

esatto è quello il punto

la metodologia di programmazione è nata seriale, la parallelizzazione della stessa avviene solo in certi ambiti

per fare un esempio triviale, i programmi che sfruttano il multicore possono farlo perchè stanno lavorando su dei dati che non sono dipendenti gli uni dagli altri

se si deve manipolare un dato lungo esempio banale un testo lunghissimo dove le A vanno sostituite con delle O (esempio banale) allora si può fare che ogni core processi una porzione del testo separatamente

ma all'interno del processo è sequenziale la routine o algoritmo il codice assembler è seguenziale le istruzioni possono essere eseguite una alla volta in sequenza

poi nelle cpu super scalari nn è proprio cosi per via delle pipeline ecc ecc ma il succo della menata è che la vera parallelizzazione non può esistere al max si rincorre a quello che c'è sopra

una istruzione (o un insieme di istruzioni) non possono essere svolte separatamente da varie cpu xke sono una seguenza di comandi se la cpu ne perde la traccia è finita

non penso

per come è nata l'architettura delle cpu (ti ricordo che per quanto le cpu nuove siano stravolte devono basarsi su una famiglia vecchiotta di cpu gli x86 appunto) è improbabile se non impossibile che una routine venga eseguita da più core contemporaneamente e nel caso fosse possibile è probabilmente controproduttivo

esempio pensa all'operazione base di una cpu, spostare i file dalla memoria a un registro e viceversa, pensa a 2 operazioni analoghe che vanno svolte in successione e la 2° deve avere il dato dalla prima

nn penso che la seconda possa fare manco un'operazione di fetch dell'istruzione senza quel dato, o nel caso fosse possibile farlo dovrebbe cmq aspettare un'attimo la risposta del secondo dato

questo prevede oltretutto che tutte le istruzioni debbano essere eseguite nello stesso tempo (stessa durata) nn sono sicuro che siano tutte uguali nelle cpu moderne

Vabbè è chiaro che se vuoi fare un'operazione su un dato in memoria, prima lo carichi in un registro e poi modifichi il dato (anche se in genere ci sono molte istruzioni che operano direttamente in memoria).
Però lo "sbarramento" che indichi tu è un problema che è stato risolto nei moderni processori Out Of Order, che riordinano le istruzioni in modo che non ci siano conflitti per poi eseguirle in parallelo.

L'architettura di Bulldozer, da quanto ho capito, è di tipo clustered core, quindi due core condividono parte delle risorse computazionali a disposizione:

http://www.hwupgrade.it/forum/showpost.php?p=28378139&postcount=11741

Vabbè è chiaro che se vuoi fare un'operazione su un dato in memoria, prima lo carichi in un registro e poi modifichi il dato (anche se in genere ci sono molte istruzioni che operano direttamente in memoria).
Però lo "sbarramento" che indichi tu è un problema che è stato risolto nei moderni processori Out Of Order, che riordinano le istruzioni in modo che non ci siano conflitti per poi eseguirle in parallelo.

L'architettura di Bulldozer, da quanto ho capito, è di tipo clustered core, quindi due core condividono parte delle risorse computazionali a disposizione:

http://www.hwupgrade.it/forum/showpost.php?p=28378139&postcount=11741


si però dipende dall'ortogonalità della cpu, in teoria l'assembler degli x86 nn è cosi certe operazioni non possono essere eseguite su dati in memoria poi nn so bene come è cambiata la cpu nel tempo xo di fatto le cpu attuali sono ancora compatibili con l'assembler di base quindi in teoria...

per l'ultima cosa non lo so :\ nn so come funziona

si però dipende dall'ortogonalità della cpu, in teoria l'assembler degli x86 nn è cosi certe operazioni non possono essere eseguite su dati in memoria poi nn so bene come è cambiata la cpu nel tempo xo di fatto le cpu attuali sono ancora compatibili con l'assembler di base quindi in teoria...


Beh quelle più semplici (e anche più importanti) hanno anche una forma con l'accesso diretto alla memoria (vedi add, inc, mul/imul, xor, and, etc...)

Beh quelle più semplici (e anche più importanti) hanno anche una forma con l'accesso diretto alla memoria (vedi add, inc, mul/imul, xor, and, etc...)

eh no

cioe almeno che nn hanno cambiato l'assembler, ma non penso senno non funzionerebbero più, la add vuole che il primo operando sia x forza un registro ne sono sicuro, le altre non so ma su questa ne sono sicuro

nn so magari hanno cambiato le cose nelle nuove cpu ?

oltretutto l'accesso in memoria nelle cpu moderne si cerca di evitarlo in ogni modo perchè poco prestazionale... nn lo so

cmq vedremo cosa ne uscirà fuori, secondo me certi applicativi saranno sempre troppo ostici da parallelizzare

eh no

cioe almeno che nn hanno cambiato l'assembler, ma non penso senno non funzionerebbero più, la add vuole che il primo operando sia x forza un registro ne sono sicuro, le altre non so ma su questa ne sono sicuro

nn so magari hanno cambiato le cose nelle nuove cpu ?

oltretutto l'accesso in memoria nelle cpu moderne si cerca di evitarlo in ogni modo perchè poco prestazionale... nn lo so

Mi sa' che ti sbagli:

http://www.giobe2000.it/Tutorial/Schede/07-IstruzioniCpu/ADD.asp

E comunque l'accesso diretto in memoria esiste perchè quando hai solo 8 registri general purpose a volte sei costretto a fare i magheggi per far funzionare il tuo algoritmo.

Mi sa' che ti sbagli:

http://www.giobe2000.it/Tutorial/Schede/07-IstruzioniCpu/ADD.asp

E comunque l'accesso diretto in memoria esiste perchè quando hai solo 8 registri general purpose a volte sei costretto a fare i magheggi per far funzionare il tuo algoritmo.

devo provare a me rompeva il cazzo l'altra sera l'assembler se ci mettevo una variabile in memoria come primo operando

pure all'uni ci hanno detto che il primo operando nn può mai essere una var in memoria :confused: boh

devo provare a me rompeva il cazzo l'altra sera l'assembler se ci mettevo una variabile in memoria come primo operando

pure all'uni ci hanno detto che il primo operando nn può mai essere una var in memoria :confused: boh

Dire una cazzata può capitare a tutti, specialmente quando uno ha in testa diverse architetture e può fare confusione.