Tutti a scuola di multicore con Intel

Avviato un programma di formazione a livello mondiale per accelerare e incrementare lo sviluppo di software ottimizzati per le nuove architetture multicore. Programmatori cercasi

Milano - Due, quattro, otto... ottanta. I core dei processori vengono ormai reclamizzati come le offerte al supermercato, e lo slogan è sempre quello: più performance, meno consumi. In realtà, come fanno notare da tempo gli esperti, c'è un altro tassello del puzzle che andrebbe considerato: il software, che nella maggioranza dei casi non è ancora ottimizzato per sfruttare appieno le decantate qualità delle architetture multi-core.

╚ per tale motivo che Intel ha deciso di richiamare tutti gli sviluppatori di software x86 sui banchi di scuola, proponendo loro corsi in cui si insegna a progettare e scrivere applicazioni per i processori multicore.

Il programma Intel Software Training offre corsi in aula e laboratori interattivi per perfezionare la formazione degli sviluppatori nella progettazione di applicazioni multi-threaded (ossia capaci di eseguire simultaneamente due o più sequenze di istruzioni facenti parte dello stesso programma). I corsi sono tenuti da istruttori certificati da Intel e sono forniti da alcune società specializzate in formazione informatica.
"I processori multicore offrono la potenza per aumentare le prestazioni del software, ma questo non avviene automaticamente né abbastanza rapidamente", ha spiegato Elliot Garbus, general manager Developer Relations Division di Intel. "Con la nuova iniziativa di training e diversi altri programmi, prodotti e strumenti concepiti per assistere la comunità di sviluppatori, Intel offre ai progettisti di software le conoscenze e le competenze necessarie per dare vita a una nuova fase di innovazione del software".

In un'era in cui il numero dei core dei microprocessori è destinato a crescere di anno in anno, formare gli sviluppatori è un'esigenza sempre più sentita dai chipmaker, soprattutto in considerazione delle novità spesso radicali introdotte nei più recenti tool di compilazione e debugging del codice.

Nell'attuale piano dei corsi non figurano ancora eventi italiani, tuttavia un portavoce di Intel Italia ha confermato a Punto Informatico che in futuro saranno organizzati corsi anche nel nostro Paese. Nel frattempo è già possibile iscriversi ai corsi online su www.intel.com/software/college o www.intel.com/go/software.
13 Commenti alla Notizia Tutti a scuola di multicore con Intel
Ordina
  • Prima che facessero i processori multicore esistevano già schede madri multicore, e avevano un mercato ben preciso: i server.
    Questo perchè ha più senso sfruttare più core da parte di più utenti, in quanto un singolo utente applica la sua attenzione a un solo processo importante per volta. Un server è destinato a servire più utenti alla volta, un personal computer invece è destinato a essere usato da un utente per volta.
    E' questo il motivo per cui esistono sistemi multicore: voler insistere nel trovare l'utilità dei multicore per i singoli utenti vuol dire ignorare le basi dell'utilizzo di un computer, oltre a ignorare che il minimo guadagno che si ha in termini di tempistica vanno quasi tutti persi con i più lunghi tempi in operazioni di I/O!

    Se volete maggiori illuminazioni: http://inutilityblog.blogspot.com/2007/07/multicor... ho perso un quarto d'ora a illustrare quello che ho sintetizzato qui sopra. Occhiolino
    non+autenticato
  • imho il multi core aiuta anche il multitasking. Dividendo i task tra i core la velocità di esecuzione dovrebbe aumentare, no?
    non+autenticato
  • - Scritto da: fabio
    > imho il multi core aiuta anche il multitasking.
    > Dividendo i task tra i core la velocità di
    > esecuzione dovrebbe aumentare,
    > no?

    corretto
    non+autenticato
  • spiacente ma il multicore non aiuta minimamente il multitask.

    Provo a spiegare questa mia affermazione evitando inutili tecnicismi...

    Un processore funziona circa così:
    1. carica i dati
    2. li elabora (5 o 6 passaggi)
    3. restituisce i risultati
    I primi processori prendevano un dato alla volta e lo elaboravano completamente prima di passare al successivo. I processori moderni (dal pentium in poi) sono in grado di "mettere in coda" i dati da elaborare: mentre il dato A è in elaborazione la cpu carica il dato B e così via.
    I processori multicore hanno più "blocchi di elaborazione" (quelli del punto 2, i core) ma non sono in grado di mettere in elaborazione 2 dati distinti a meno che il processo (task) non sia stato creato in modo da chiedere l'elaborazione in parallelo di 2 o più gruppi di dati.

    Il multitask non esiste:
    con il termine multitask si intende la capacità di fare 2 (o più) cose contemporaneamente ma questo non è possibile: o fai una cosa o ne fai un'altra oppure le fai a momenti alterni, e questo è quello che succede.
    Mentre io scrivo questo post, tra una lettera e l'altra passa un decimo di secondo, la cpu del mio pc in un sec fa qualche migliardata di cicli, quindi mentre aspetta che il lentissimo umano gli dia un input si passa il tempo a far girare l'antivirus, controlla la posta con Thunderbird in background, controlla se gli è stata collegata una nuova periferica, se si mi chiede se la voglio installare (o la installa d'ufficio) e così via. In particolare si dedica completamente, per qualche centesimo di secondo, ad ogni processo attivo (task1 - tastk2 .. task125 - task1 - task2 .. task125 ... ecc) a ruota.
    In questo modo, grazie alla velocità delle macchine attuali, abbiamo l'impressione che più processi vengano eseguiti contemporaneamente.
    Es: è come imboccare 3 bambini con un cucchiaio solo, dai un boccone al primo, mentre questo mastica e ingoia dai un boccone al secondo e uno al terzo. Per i babini i bocconi arrivano uno dietro l'altro mentre tu dedichi 5 secondi al primo, 5 al secondo e 5 al terzo per poi ricominciare.

    Per avere multitask dovresti avere tutte le risorse doppie (come avere 2 pc in parallelo o 3 cucchiai e 3 braccia).

    In pratica il multicore riduce i tempi di elaborazione del singono task ma non può eseguire 2 task contemporaneamente (per tornare all'esempio dei bimbi è come avere 3 cucchiai ma "solo" 2 braccia).

    Spero di essere stato chiaro e non aver generato più confusione che chiarezza.
    non+autenticato
  • - Scritto da: Pietro
    > spiacente ma il multicore non aiuta minimamente
    > il
    > multitask.

    Ma allora gli ultimi server della Sun, IBM ecc. che oltre ad essere multiprocessore sono multicore a cosa servono?
    Ed infatti i server sono la massima espressione del multitasking più che del multithreading.

    > I primi processori prendevano un dato alla volta
    > e lo elaboravano completamente prima di passare
    > al successivo. I processori moderni (dal pentium
    > in poi) sono in grado di "mettere in coda" i dati
    > da elaborare: mentre il dato A è in elaborazione
    > la cpu carica il dato B e così
    > via.
    > I processori multicore hanno più "blocchi di
    > elaborazione" (quelli del punto 2, i core) ma non
    > sono in grado di mettere in elaborazione 2 dati
    > distinti a meno che il processo (task) non sia
    > stato creato in modo da chiedere l'elaborazione
    > in parallelo di 2 o più gruppi di
    > dati.

    a me sembra invece che a parte il lato I/O e bus periferici in genere (che hanno indubbiamente un peso enorme), i singoli core di un multicore sono praticamente dei processori (hanno le loro ALU e registri), solo che sono nello stesso package. Hanno pure una loro cache (dedicata o separata che sia).

    > Il multitask non esiste:
    > con il termine multitask si intende la capacità
    > di fare 2 (o più) cose contemporaneamente ma
    > questo non è possibile: o fai una cosa o ne fai
    > un'altra oppure le fai a momenti alterni, e
    > questo è quello che
    > succede.
    > Per avere multitask dovresti avere tutte le
    > risorse doppie (come avere 2 pc in parallelo o 3
    > cucchiai e 3
    > braccia).
    > In pratica il multicore riduce i tempi di
    > elaborazione del singono task ma non può eseguire
    > 2 task contemporaneamente (per tornare
    > all'esempio dei bimbi è come avere 3 cucchiai ma
    > "solo" 2
    > braccia).

    E' chiaro che un multitasking puro non esiste, (anche nel caso di multiprocessori infatti ci sono comunque i bus di I/O in condivisione). Ma mi sa che quindi dipende dal tipo di risorse di cui il processo ha bisogno in una certa fase dell'elaborazione.

    Se tutti i task hanno pesantemente bisogno della parte I/O (come nel caso dell'interazione con l'utente) allora è come dici tu. Ma se invece ce ne sono altri che praticamente non interagiscono con l'utente (come un antivirus in background), puoi associare tale task ad un core (i sistemi operativi vedono il core come se fosse un processore).
    Con tutti i limiti del caso, in quanto ad esempio l'accesso al disco e alla ram sono naturalmente in mutua esclusione, se dei task, per la maggiorparte del tempo di elaborazione, hanno semplicemente bisogno di un core e della sua cache, hai praticamnte multitasking.
  • - Scritto da: Overnoise
    > Ma allora gli ultimi server della Sun, IBM ecc.
    > che oltre ad essere multiprocessore sono
    > multicore a cosa
    > servono?
    > Ed infatti i server sono la massima espressione
    > del multitasking più che del
    > multithreading.

    Il fatto che un processore multicore sia meglio di un processore singlecore è fuori discussione (altrimenti non avrebbe senso la loro esisteza), a parità di clock è più veloce, quindi possiamo abbassare il clock e avere comunque prestazioni maggiori, consumi e riscaldamento inferiori. I server hanno bisogno di grande potenza di calcolo e quindi migliorare il processore migliora le prestazioni dell'intero server.

    > a me sembra invece che a parte il lato I/O e bus
    > periferici in genere (che hanno indubbiamente un
    > peso enorme), i singoli core di un multicore sono
    > praticamente dei processori (hanno le loro ALU e
    > registri), solo che sono nello stesso package.
    > Hanno pure una loro cache (dedicata o separata
    > che
    > sia).

    Vero! E questo è il motivo per cui un processore multicore è più veloce di un singlecore.

    > E' chiaro che un multitasking puro non esiste,
    > (anche nel caso di multiprocessori infatti ci
    > sono comunque i bus di I/O in condivisione). Ma
    > mi sa che quindi dipende dal tipo di risorse di
    > cui il processo ha bisogno in una certa fase
    > dell'elaborazione.
    >
    > Se tutti i task hanno pesantemente bisogno della
    > parte I/O (come nel caso dell'interazione con
    > l'utente) allora è come dici tu. Ma se invece ce
    > ne sono altri che praticamente non interagiscono
    > con l'utente (come un antivirus in background),
    > puoi associare tale task ad un core (i sistemi
    > operativi vedono il core come se fosse un
    > processore).
    > Con tutti i limiti del caso, in quanto ad esempio
    > l'accesso al disco e alla ram sono naturalmente
    > in mutua esclusione, se dei task, per la
    > maggiorparte del tempo di elaborazione, hanno
    > semplicemente bisogno di un core e della sua
    > cache, hai praticamnte
    > multitasking.

    Ipoteticamente corretto ma solo se, come dici tu, hanno semplicemente bisogno di un core e della sua cache. Ma non ci sono dei task del genere nei pc dei comuni mortali. Gli unici task con simili caratteristiche sono quelli citati da rockroll (il primo post dell'articolo), tutti gli altri devono interaggire con la ram e/o l'hd.

    Vorrei farti notare inoltre che il prcessore non elabora interi processi (tipo antivirus) in una botta, il processo è diviso in istruzioni e ad ogni ciclo di clock ne viene eseguita una (in effetti non è corretto in quanto ad ogni ciclo di clock il processore sposta l'istruzione da una fase all'altra: caricamento-elaborazione-restituzione, quindi servono più cicli per risolvere un'istruzione).

    Inoltre ti ricordo che la cache è di 1 o 2 Mb, quanto tempo credi impieghi un processore moderno ad elaborare 2Mb? e Quanta roba credi di caricare in 2 mb? Il processore carica dalla RAM alla cache, poi prende un pezzetto alla volta di quello che trova in cache lo carica nei registri, li lo elabora e rimette i risultati nella cache, dalla cache viene infine rimesso tutto in RAM.
    non+autenticato
  • Temo proprio di si.

    Gli sforzi di Intel di istruire programmatori multithread di cui parla l'articolo rischiano di essere vani, o meglio di utilità temporanea, perchè richia di essere temporanea l'attuale tendenza alle soluzioni MultiCore.

    Al momento non si è in grado di raggiungere in normale produzione HW velocità di clock oltre un certo limite, per limiti fisici della tecnologia al silicio non lontani
    dall'essere raggiunti. Quindi al momento è un passo obbligato sperperare risorse di produzione ricorrendo a soluzioni di multicore e multicpu più o meno "incollate" insieme, se proprio vogliamo sperare di superare in qualche modo ed in qualche caso le prestazioni di CPU dei migliori monocore in produzione, che già di loro sono dei piccoli mostri più che sufficienti alle esigenze più pesanti, a patto di non estenuarli con applicazioni non adeguatamente ottimizzate e con certi S.O. pachidermici purtroppo ben diffusi se non addirittura imposti da specifiche politiche di mercato...

    Per le storture di un mercato per altro pensato per una ristretta cerchia di applicazioni professionali, ma ampliatosi innaturalmente per le mania dell'utonto ad "avere comunque il meglio" illuso da altrettanto innaturali benchmark anche se in pratica ben poco sfruttabile, si è arrivati ad avere proliferazioni di n cores su Computers "di tendenza" che qualunque ragazzotto viziato o figlio di babbo consenziente ambisce ad avere a qualunque costo per non sentirsi menomato.
    La cosa mi fa ricordare le Timberland e i Monclair degli assurdi Paninari dei miei tempi!

    Ma allora, se nel 90% dei casi almeno si tratta di moda di tendenza piuttosto che di reale esigenza, quanto durerà tutto questo?
    Non solo, ma quanto credete che ci vorrà ancora perchè nuove tecnologie, ancora allo studio, diventino realtà produttiva innalzando di botto, magari di un ordine di grandezza, le frequenze di clock attualmente raggiungibili? A quel punto le faticosissime ricodifiche in MultiThreading fino ad allora effettuate diventeranno fatica sprecata.
    Meglio sarebbe stata la decisamente più facile conversione a 64 bit, che tutti i processori da anni supportano ma nessuno praticamente sfrutta. La conversione a 64 bit non sarebbe fatica sprecata, e darebbe comunque vantaggio sempre e non nei pochi casi in cui il multithread ha senso.
    Per comprendere il tutto, specie l'ultima frase, è meglio ricordare alcuni concetti teorici sull'argomento.

    Potenziare la CPU ha senso solo quando ci si trova in continua presenza di specifiche elaborazioni "CPU bound" ovvero di programmi "scientifici", dove il collo di bottiglia è rappresentato dalla potenza della CPU piuttosto che dalle in proporzione lentissime operazioni di I/O. La norma è che le operazioni di Input/Ouput siano il punto debole della catena, poi verrebbero i tempi di risposta dei canali, delle memorie, dei Bus... e da ultimo di regola i problemi potrebbero risiedere nella velocità del processore ovvero nei tempi di clock di esecuzione delle istruzioni.
    Nelle normali elaborazioni il tempo di clock conta poco, e questo spiega come mai ad esempio i processori AMD, con clock di 3/4 quello dichiarato dagli Intel, raggiungano in normale sessione di lavoro prestazioni almeno equivalenti (o superiori magari per migliori soluzioni di contorno); ci sarà pure un motivo se con un clock di soli 2000 MHz un AMD Sempron si può fregiare della sigla 3300+, e quel numero sapete bene che significato ha. Certo che se andiamo poi a fare benchmark con programmi escusivamente CPU bound conterà solo la frequanza di clock, ma si tratta di qui casi "professionali" che toccano forse manco il 10% dell'utenza, ed a costoro non sono certo rivolte le mie critiche (rendering grafico, compressioni e conversioni multimediali, simulazioni modelli matematici, elaborazioni statistiche a ricerca euristica... ecc.).
    (E' chiaro che in un discorso serio non vado a tener conto dei giochini tanti cari ai più viziati di noi, giochini che poi hanno più bisogno di GPU che di CPU...)

    Ma sono proprio i programmi professionali CPU bound di cui sopra quelli già da tempo scritti, se e per quanto possibile, con metodologia MultiThread, e con giusta ragione.
    Gli altri, abbiate pazienza, non ne hanno proprio bisogno, perchè il tempo di pedana (anzi di scrivania, da inizio a fine elaborazione), è determinato in misura totale da tutt'altri fattori (normalmente tempi di I/O); anzi di CPU ne avanza a volontà, ed i tempi morti di attesa I/O possono essere pienamente sfruttati da altri task (lavori) contemporanei senza alcun bisogno di CPU supplementari, e tutti i S.O. sono da sempre attrezzati a questa funzione (MultiTasking) e proprio non altrettanto al MultiThreading...

    Vorrei ora spiegare la ragione di quella frase in neretto: "se e per quanto possibile".
    Certo, non per tutti i programmi ha senso il multithread, ovvero per certi non è proprio possibile, senza contare che solo in piccole parti degli stessi programmi si può arrivare ad un multithread elevato, condizione necessaria per sfruttare, per lo meno in quei momenti, un numero di cores parimenti elevato. Se ad esempio un programma è rivisto per farlo girare su due cores, non conterrà multithread di livello superiore a due e non potrà mai sfruttare più dei primi due cores.
    Allora, ovviamente sempre restando nel caso, forse uno su cento, in cui un programma è sufficientemente scientifico (CPU bound) da mettere in crisi la potenza di calcolo della CPU, e sopratutto non sia stata ancora scritta la versione "multithread", non è detto che lo stesso contenga parti parallelizzabili, e se le contiene non è detto che esse siano tanto significative da meritare la revisione in multithread. Per capirci faccio un paio di esempi. Un programma di conversione filmati da Mpeg2 ad avi DivX può essere visto a "fette" di input, ciascuna fetta può essere convertita per conto da un suo core di processo, perchè il contenuto di una fetta non condiziona l'elaborazione di un'altra fetta, ed ogni porzione può essere elaborata contemporaneamente alle altre su core diversi, accodando alla fine gli output ottenuti: è un programma parallelizzabile idealmente a qualunque livello di MultiThreading. Un altro programma invece, decisamente scientifico, calcola per incrementi infinitesimi successivi la traiettoria di una navicella spaziale dotata di certi valori inerziali iniziali, sotto l'influenza gravitazionale della Terra e della Luna (per tre corpi in moto in reciproca attrazione non esiste a tutt'oggi metodo di calcolo specifico).
    In una programma del genere non esiste alcuna possibilità di parallelismo, ogni istruzione ha bisogno del risultato del calcolo di quella precedente...

    Ora ditemi voi quanti programmi pensate che avranno davvero bisogno di conversioni in multithreading?

    Bye - rockroll
  • La maggio r parte del SW in giro e per l'uso amministrativo / gestionale delle aziende. Quindi registrazioni e letture di DB dove ci sono i dati per : magazzino / bolle / fatture/ articoli / ordini / ecc....
    questo è quello ad esempio che c'è nella mia azienda.
    TANTA RAM E DISCHI SCSI U320 FANNO LA DIFFERENZA neitempi di elaborazione.
    non+autenticato
  • Temo proprio di si.

    Gli sforzi di Intel di istruire programmatori multithread di cui parla l'articolo rischiano di essere vani, o meglio di utilità temporanea, perchè richia di essere temporanea l'attuale tendenza alle soluzioni MultiCore.

    Al momento non si è in grado di raggiungere in normale produzione HW velocità di clock oltre un certo limite, per limiti fisici della tecnologia al silicio non lontani
    dall'essere raggiunti. Quindi al momento è un passo obbligato sperperare risorse di produzione ricorrendo a soluzioni di multicore e multicpu più o meno "incollate" insieme, se proprio vogliamo sperare di superare in qualche modo ed in qualche caso le prestazioni di CPU dei migliori monocore in produzione, che già di loro sono dei piccoli mostri più che sufficienti alle esigenze più pesanti, a patto di non estenuarli con applicazioni non adeguatamente ottimizzate e con certi S.O. pachidermici purtroppo ben diffusi se non addirittura imposti da specifiche politiche di mercato...

    Per le storture di un mercato per altro pensato per una ristretta cerchia di applicazioni professionali, ma ampliatosi innaturalmente per le mania dell'utonto ad "avere comunque il meglio" illuso da altrettanto innaturali benchmark anche se in pratica ben poco sfruttabile, si è arrivati ad avere proliferazioni di n cores su Computers "di tendenza" che qualunque ragazzotto viziato o figlio di babbo consenziente ambisce ad avere a qualunque costo per non sentirsi menomato.
    La cosa mi fa ricordare le Timberland e i Monclair degli assurdi Paninari dei miei tempi!

    Ma allora, se nel 90% dei casi almeno si tratta di moda di tendenza piuttosto che di reale esigenza, quanto durerà tutto questo?
    Non solo, ma quanto credete che ci vorrà ancora perchè nuove tecnologie, ancora allo studio, diventino realtà produttiva innalzando di botto, magari di un ordine di grandezza, le frequenze di clock attualmente raggiungibili? A quel punto le faticosissime ricodifiche in MultiThreading fino ad allora effettuate diventeranno fatica sprecata.
    Meglio sarebbe stata la decisamente più facile conversione a 64 bit, che tutti i processori da anni supportano ma nessuno praticamente sfrutta. La conversione a 64 bit non sarebbe fatica sprecata, e darebbe comunque vantaggio sempre e non nei pochi casi in cui il multithread ha senso.
    Per comprendere il tutto, specie l'ultima frase, è meglio ricordare alcuni concetti teorici sull'argomento.

    Potenziare la CPU ha senso solo quando ci si trova in continua presenza di specifiche elaborazioni "CPU bound" ovvero di programmi "scientifici", dove il collo di bottiglia è rappresentato dalla potenza della CPU piuttosto che dalle in proporzione lentissime operazioni di I/O. La norma è che le operazioni di Input/Ouput siano il punto debole della catena, poi verrebbero i tempi di risposta dei canali, delle memorie, dei Bus... e da ultimo di regola i problemi potrebbero risiedere nella velocità del processore ovvero nei tempi di clock di esecuzione delle istruzioni.
    Nelle normali elaborazioni il tempo di clock conta poco, e questo spiega come mai ad esempio i processori AMD, con clock di 3/4 quello dichiarato dagli Intel, raggiungano in normale sessione di lavoro prestazioni almeno equivalenti (o superiori magari per migliori soluzioni di contorno); ci sarà pure un motivo se con un clock di soli 2000 MHz un AMD Sempron si può fregiare della sigla 3300+, e quel numero sapete bene che significato ha. Certo che se andiamo poi a fare benchmark con programmi escusivamente CPU bound conterà solo la frequanza di clock, ma si tratta di qui casi "professionali" che toccano forse manco il 10% dell'utenza, ed a costoro non sono certo rivolte le mie critiche (rendering grafico, compressioni e conversioni multimediali, simulazioni modelli matematici, elaborazioni statistiche a ricerca euristica... ecc.).
    (E' chiaro che in un discorso serio non vado a tener conto dei giochini tanti cari ai più viziati di noi, giochini che poi hanno più bisogno di GPU che di CPU...)

    Ma sono proprio i programmi professionali CPU bound di cui sopra quelli già da tempo scritti, se e per quanto possibile, con metodologia MultiThread, e con giusta ragione.
    Gli altri, abbiate pazienza, non ne hanno proprio bisogno, perchè il tempo di pedana (anzi di scrivania, da inizio a fine elaborazione), è determinato in misura totale da tutt'altri fattori (normalmente tempi di I/O); anzi di CPU ne avanza a volontà, ed i tempi morti di attesa I/O possono essere pienamente sfruttati da altri task (lavori) contemporanei senza alcun bisogno di CPU supplementari, e tutti i S.O. sono da sempre attrezzati a questa funzione (MultiTasking) e proprio non altrettanto al MultiThreading...

    Vorrei ora spiegare la ragione di quella frase in neretto: "se e per quanto possibile".
    Certo, non per tutti i programmi ha senso il multithread, ovvero per certi non è proprio possibile, senza contare che solo in piccole parti degli stessi programmi si può arrivare ad un multithread elevato, condizione necessaria per sfruttare, per lo meno in quei momenti, un numero di cores parimenti elevato. Se ad esempio un programma è rivisto per farlo girare su due cores, non conterrà multithread di livello superiore a due e non potrà mai sfruttare più dei primi due cores.
    Allora, ovviamente sempre restando nel caso, forse uno su cento, in cui un programma è sufficientemente scientifico (CPU bound) da mettere in crisi la potenza di calcolo della CPU, e sopratutto non sia stata ancora scritta la versione "multithread", non è detto che lo stesso contenga parti parallelizzabili, e se le contiene non è detto che esse siano tanto significative da meritare la revisione in multithread. Per capirci faccio un paio di esempi. Un programma di conversione filmati da Mpeg2 ad avi DivX può essere visto a "fette" di input, ciascuna fetta può essere convertita per conto da un suo core di processo, perchè il contenuto di una fetta non condiziona l'elaborazione di un'altra fetta, ed ogni porzione può essere elaborata contemporaneamente alle altre su core diversi, accodando alla fine gli output ottenuti: è un programma parallelizzabile idealmente a qualunque livello di MultiThreading. Un altro programma invece, decisamente scientifico, calcola per incrementi infinitesimi successivi la traiettoria di una navicella spaziale dotata di certi valori inerziali iniziali, sotto l'influenza gravitazionale della Terra e della Luna (per tre corpi in moto in reciproca attrazione non esiste a tutt'oggi metodo di calcolo specifico).
    In una programma del genere non esiste alcuna possibilità di parallelismo, ogni istruzione ha bisogno del risultato del calcolo di quella precedente...

    Ora ditemi voi quanti programmi pensate che avranno davvero bisogno di conversioni in multithreading?

    Bye - rockroll
  • In ambiente di produzione 2 o 4 core possono anche far comodo. Nel senso di poter assegnare a ciascuno un'applicazione molto poco multithread.
    non+autenticato
  • - Scritto da: rockroll

    > Gli sforzi di Intel di istruire programmatori multithread
    > di cui parla l'articolo rischiano di essere vani, o
    > meglio di utilità temporanea, perchè richia di essere
    > temporanea l'attuale tendenza alle soluzioni MultiCore.

    E' una tendenza che muove miliardi (per intel).

    > Al momento non si è in grado di raggiungere in normale
    > produzione HW velocità di clock oltre un certo limite,
    > per limiti fisici della tecnologia al silicio non lontani
    > aall'essere raggiunti. Quindi al momento è un passo
    > obbligato sperperare risorse di produzione ricorrendo a
    > soluzioni di multicore e multicpu più o meno "incollate"
    > insieme, se proprio vogliamo sperare di superare in
    > qualche modo ed in qualche caso le prestazioni di CPU dei
    > migliori monocore in produzione, che già di loro sono dei
    > piccoli mostri più che sufficienti alle esigenze più
    > pesanti, a patto di non estenuarli con applicazioni non
    > adeguatamente ottimizzate e con certi S.O. pachidermici
    > purtroppo ben diffusi se non addirittura imposti da
    > specifiche politiche di mercato...

    Di questo a intel non importa proprio nulla. Anzi, piu' i S.O. sono pachidermici piu' loro sono giustificati a produrre processori multicore per supportarli meglio.

    > Per le storture di un mercato per altro pensato per una
    > ristretta cerchia di applicazioni professionali, ma
    > ampliatosi innaturalmente per le mania dell'utonto ad
    > "avere comunque il meglio" illuso da altrettanto
    > innaturali benchmark anche se in pratica ben poco
    > sfruttabile, si è arrivati ad avere proliferazioni di n
    > cores su Computers "di tendenza" che qualunque ragazzotto
    > viziato o figlio di babbo consenziente ambisce ad avere a
    > qualunque costo per non sentirsi menomato.
    > La cosa mi fa ricordare le Timberland e i Monclair degli
    > assurdi Paninari dei miei tempi!

    Esatto, e' proprio cosi'.

    Per il resto, quoto tutto, ma non credo che possa trattarsi di moda, visto che se la "moda" finisse e si ritornasse al passato quei sistemi pachidermici (che, ricordiamolo, molti utonti utilizzano) che gia' ora sono lenti, diventerebbero inutilizzabili. E non credo proprio che microsoft decida di cominciare a produrre s.o. piu' leggeri e snelli.

    Quindi forse passeranno i multicore, ma verranno comunque sostituiti da prodotti altrettanto sovradimensionati per le esigenze dell'utonto medio. Potenza del marketing.
    d
    160
  • Non trovo più l'articolo (e non ho avuto tempo di rintracciarlo in rete) ma nell'autunno 2005 in Israele (uno dei paesi tecnologicamente più avanzati) hanno creato un processore che viaggiava a 8Thz meglio conosciuti come 8000 GigaHerz (noi avevamo da poco sforato il 1Ghz).

    Per ottenere questo risultato utilizzavano una nuova tecnologia al laser, in pratica le i transistor e i collegamenti tra questi avvenivano tramite fasci di luce anziché corrente elettrica (ovviando così ai limiti di cui hai accennato).

    Il fatto strano è che ormai sono passati quasi 2 anni e non si è più sentito nulla.
    non+autenticato
  • non sono d'accordo, se un dual core ha piu potenza di calcolo di un single core (a parita di transistor) ad un certo clock, mantiene il vantaggio anche aumentando la frequenza. poi chiaro che se inventassero ad esempio un modo di fare processori ottici con frequenze molto piu elevate ma meno miniaturizzati tornerebbe conveniente fare processori single core, che sarebbero piu efficienti di un dual core di pari complessita.
    non si è capito nulla del post eh? Angioletto

    per quanto riguarda il discorso della potenza che non serve, scusa se te lo dico ma sono anni che si sente ma la potenza in piu la utilizziamo eccome Occhiolino
    non+autenticato