Il multi-core nei compilatori Intel

Il gigante dei chip ha aggiornato i propri compilatori per i linguaggi C++ e Fortran aggiungendovi funzionalità ottimizzate per la nuova generazione di processori multi-core

Santa Clara (USA) - Intel ha annunciato nuove versioni aggiornate dei propri compilatori capaci, a suo dire, di "schiudere le potenzialità delle piattaforme multi-core".

Le release 9.0 dei compilatori di Intel per C++ e Fortran sono state studiate per aiutare gli sviluppatori a scrivere codice ottimizzato per il multi-threading, una tecnica capace di incrementare le performance di calcolo eseguendo simultaneamente differenti parti di uno stesso programma. La programmazione multi-threading è di cruciale importanza per sfruttare a fondo le nuove generazioni di CPU, e in particolare quelle basate sulla tecnologia Hyper-Threading di Intel e quelle dotate di due o più core.

I compilatori, che si occupano di tradurre un linguaggio di programmazione (come il C++) nel linguaggio macchina comprensibile al processore, svolgono un ruolo importantissimo nell'ottimizzare le performance dei programmi. Quelli di Intel includono una funzione, detta auto-parallelization, che analizza il codice alla ricerca di opportunità per creare più thread di esecuzione: il chipmaker ammette che questa funzione non può sostituirsi alla perizia e all'abilità del programmatore ma, in molti casi, aiuta a generare binari più efficienti e ottimizzati per le moderne architetture multi-threading.
Il colosso californiano ha poi spiegato che i propri compilatori consentono il debugging anche del codice ottimizzato. "Tradizionalmente - ha dichiarato Intel - l'uso di un optimizer rende il debugging difficile o impossibile".

Entrambi i compilatori sono compatibili con la recente specifica 2.5 di OpenMP, un'API (Application Program Interface) standard per il multi-processing, e includono funzionalità per la riduzione dei buffer overflow specifiche per Linux.

Intel aveva già introdotto nei propri compilatori il supporto alle proprie CPU Hyper-Threading a partire dalle versioni 7.0, rilasciate alla fine del 2002. Un anno dopo il chipmaker ha lanciato invece le versioni 8.0, ottimizzate per i processori con core Prescott e per le ultime generazioni di chip XScale.

L'Intel C++ Compiler e l'Intel Fortran Compiler sono disponibili per Windows e Linux al prezzo, rispettivamente, di 399 e 499 dollari.
TAG: sw
13 Commenti alla Notizia Il multi-core nei compilatori Intel
Ordina

  • E' falso. Fumo negli occhi.

    Non esiste e non esisterà mai alcun
    compilatore capace di tradurre un
    linguaggio in istruzioni ottimizzate
    per più cpu che funzionano in parallelo.
    Non solo la maggior parte degli algoritmi
    sono inerentemente NON parallelizzabili,
    ma anche quei pochi che lo sono devono
    essere appositamente strutturati già
    dal programmatore per evitare dipendenze,
    cosa che un compilatore semplicemente
    non può sapere in anticipo quando va a
    generare il codice.

    In sostanza, quella di Intel è una bufala
    per chi non capisce nulla di informatica.
    Ormai sono talmente disperati dal fatto
    che AMD li sta surclassando in tutto, che
    non sanno più a che inventarsi...
    non+autenticato
  • "Quelli di Intel includono una funzione, detta auto-parallelization, che analizza il codice alla ricerca di opportunità per creare più thread di esecuzione: il chipmaker ammette che questa funzione non può sostituirsi alla perizia e all'abilità del programmatore ma, in molti casi, aiuta a generare binari più efficienti e ottimizzati per le moderne architetture multi-threading."


    Prima di parlare di informatica, impara a capire l'italiano.
    non+autenticato
  • infatti dice:
    "sono state studiate per aiutare gli sviluppatori a scrivere codice ottimizzato per il multi-threading"

    non dice: "faccio miracoli"Sorride
    eg
    116
  • > quella di Intel è una bufala
    > per chi non capisce nulla di informatica.

    e secondo te come fanno i processori ad eseguire in parallelo 2 o più threads? Usando un algorimo, che quindi esiste ed è possibile utilizzare per ottimizzare in partenza i programmi.
    non+autenticato

  • - Scritto da: Anonimo
    > > quella di Intel è una bufala
    > > per chi non capisce nulla di informatica.
    >
    > e secondo te come fanno i processori ad eseguire
    > in parallelo 2 o più threads? Usando un algorimo,
    > che quindi esiste ed è possibile utilizzare per
    > ottimizzare in partenza i programmi.

    ??? Ma che hai fumato?
    non+autenticato
  • > e secondo te come fanno i processori ad eseguire
    > in parallelo 2 o più threads? Usando un algorimo,
    > che quindi esiste ed è possibile utilizzare per
    > ottimizzare in partenza i programmi.
    sbagliato.
    una unità di calcolo fa necessariamente una cosa alla volta.
    un core ne ha diverse di unità di calcolo, ma queste possono fare più cose contemporaneamente solo se:
    1) le risorse richieste (specifici circuiti) sono liberi;
    2) ciascuna cosa non influisce sull'altra es se viene testa fai x se viene croce fai y, prima di avere il risultato di testa o croce non posso eseguire x o y, a volte (come nell'esempio) posso speculativamente eseguirli tutte le ramificazioni e scegliere la strada giusta (sarebbe più difficile se fosse "dammi in intero casuale", avrei 4 mld di ramificazioniDeluso ) ma sempre se ci sono, tra le molte risorse, unità adatte libere. Se le varie parti in esecuzione non si influenzano (multiprocesso, multitask, multithread tra di loro indipendenti... a seconda della granularità del sistema, dove una maggiore granularità in genre aiuta) si tratta sempre di aspettare di avere le necessarie risorse libere.
    Da qui la non perfetta scalabilità empiricamente rilevabile delle prestazioni "sui generis" del calcolo parallelo.
    Poi ci sono algoritmi che non si prestano per nulla alla parallelizzazione (quindi più subunità, più core o più cpu servono "solo" a smalitire altri task/thread/processi e la macchina rimane più responsiva anche se la specifica elaborazione di quel calcolo non si avvantaggia) ed altre che ne traggono enormi benefici, fermo restando che la scalabilità di risorse/prestazioni non sarà mai 1:1 se non in condizioni teoriche praticamente mai raggiungibili (il famoso teorema degli n uomini che non possono scavare una buca nel tempo/n impiegato da un uomo solo)

    ==================================
    Modificato dall'autore il 16/06/2005 10.23.32
    non+autenticato
  • > 1) le risorse richieste (specifici circuiti) sono
    > liberi;
    > 2) ciascuna cosa non influisce sull'altra es se
    > viene testa fai x se viene croce fai y, prima di
    > avere il risultato di testa o croce non posso
    > eseguire x o y, a volte (come nell'esempio) posso
    > speculativamente eseguirli tutte le ramificazioni
    > e scegliere la strada giusta

    appunto tutte quelle cose possono essere fatte oltre che via software anche via hardware analizzando le istruzioni del programma che stanno dentro alla cache della cpu
    non+autenticato
  • > appunto tutte quelle cose possono essere fatte
    > oltre che via software anche via hardware
    > analizzando le istruzioni del programma che
    > stanno dentro alla cache della cpu
    non hai capito.
    se una risorsa per l'esecuzione non è libera non è libera
    se non ci sono altre risorse (subunità adatte) non può essere eseguito il compito
    se ci sono condizioni logiche per cui il compito non possa essere eseguito prima o insieme ad un altro (cioè, non ci sono i presupposti per ooe o parallelismo) dovrà logicamente essere eseguito sequenzialmente.
    in altre parole, se un uomo scava una buca in 10 minuti cento uomini non scaveranno mai una buca in 0,1minuti.
    non+autenticato
  • > non hai capito.
    > se una risorsa per l'esecuzione non è libera non
    > è libera
    > se non ci sono altre risorse (subunità adatte)
    > non può essere eseguito il compito
    > se ci sono condizioni logiche per cui il compito
    > non possa essere eseguito prima o insieme ad un
    > altro (cioè, non ci sono i presupposti per ooe o
    > parallelismo) dovrà logicamente essere eseguito
    > sequenzialmente.
    > in altre parole, se un uomo scava una buca in 10
    > minuti cento uomini non scaveranno mai una buca
    > in 0,1minuti.

    si ma se ci sono l'esecuzione parallela andrà a buon fine, mentre se non ci sono l'esecuzione normalmente, è questa la differenza! Mentre con i compilatori normali viene dato per scontato che la condizione di esecuzione parallela non sia mai verificata.
    non+autenticato
  • > non hai capito.
    > se una risorsa per l'esecuzione non è libera non
    > è libera
    > se non ci sono altre risorse (subunità adatte)
    > non può essere eseguito il compito
    > se ci sono condizioni logiche per cui il compito
    > non possa essere eseguito prima o insieme ad un
    > altro (cioè, non ci sono i presupposti per ooe o
    > parallelismo) dovrà logicamente essere eseguito
    > sequenzialmente.
    > in altre parole, se un uomo scava una buca in 10
    > minuti cento uomini non scaveranno mai una buca
    > in 0,1minuti.

    si ma se ci sono l'esecuzione parallela andrà a buon fine, mentre se non ci sono l'esecuzione procede normalmente, è questa la differenza! Mentre con i compilatori normali viene dato per scontato che la condizione di esecuzione parallela non sia mai verificata.
    non+autenticato
  • > Mentre con i compilatori normali viene dato per
    > scontato che la condizione di esecuzione
    > parallela non sia mai verificata.
    No, il parallelismo c'è in molti modi diversi:
    - a livello di istruzioni simd/mimd
    - internamente al core tra le varie risorse di calcolo disponibili tramite una gestione intelligente delle istruzioni (traduzione in istruzioni più semplici parallelizzabili ed eseguibili in più stadi) e/o tramite un supporto intelligente ai thread/task/processi (in soldoni per capire quando due cose possono essere eseguite insieme, se l erisorse ci sono, senza avere influenza l'una sull'altra)
    - tra più core sullo stesso integrato
    - tra più cpu sulla stessa piastra madre
    - tra più macchine in un cluster o grid
    ecc ecc

    intrenamente ad un processore non è che c'è una unica unità di calcolo che fa tutto ma più tante risorse granulari che, genericamente, servono a fare determinate cose e che per essere utilizzate devono ovviamente essere libere.
    ad es sui vecchi pentium1 esiste già una pipeline che esegue quello che può in modo parallelo e facendo speculativo traducendo le istruzioni cisc in più semplici istruzioni risc che sono eseguite in diversi stadi, più istruzioni alla volta per ciclo, sui pentium mmx venne aggiunto un ulteriore tipo di parallelismo, quello a livello di uistruzioni, mmx appunto dove una m sta per multiplo (8 byte alla volta possono essere elaborati in una unica istruzione, simd, single instruction multiple data).

    Insomma, il parallelismo esiste da moltissimo tempo ed in moltissimi modi a tutti i livelli di calcolo e anche i compilatori più datati in circolazione ne tengono conto.
    Questo ha il vantaggio di avere in più un possibile targhet specifico che tiene nel dovuto conto:
    l'architettura netburst dei p4
    l'hyperthreading del P4
    lo specifico funzionamento dei P4 multicore
    ma non è che prima i compilatori (anche limitandoci a quelli rilasciati da Intel) non consentissero di copilare applicazioni parallelizzate in almeno qualche livello, da un bel po di anni abbiamo applicazioni parallelizzate dove si può parallelizzare che fanno uso di mimd/simd, che ottimizzano per processori che hanno una esecuzione su pipeline fortemente speculativa e parallelizzata, che usano più core o più cpu (banalmente basta che scrivi una applicazione che crea due tread e vedrai che se uno impegna il primo core o la prima cpu l'altro non farà finta di niente come suggerisci ma passerà autonomamente sulla seconda unità)
    non+autenticato