di  -  martedì 7 luglio 2009

Il titolo è, ovviamente, provocatorio, in quanto, come risulterà evidente, l’adozione di architetture multicore non è dettata da mere scelte  modaiole e il loro utilizzo porta non pochi benefici. Sarebbe il caso, però, di indagare sui motivi che hanno spinto i progettisti ad abbandonare la strada della rincorsa alle frequenze e delle architetture superpipelined per imboccare quella del multichip o del multicore.

In questo articolo, avevo fatto cenno ad alcuni dei problemi ai quali si va incontro nei processi di scaling e ad una parte dei limiti che si stanno incontrando con le attuali tecnologie. In quest’altro articolo, si era fatto cenno a come si sviluppa l’idea di architettura pipelined ma anche a quali possono essere i principali svantaggi a cui si va incontro nel momento in cui si esaspera il concetto di pipeline e si cerca di ridurre il più possibile la dimensione degli stadi, aumentandone il numero e la frequenza di funzionamento. Infine, in quest’altro articolo, erano state messe a confronto le varie architetture ed era stata fatta una breve disamina delle caratteristiche di alcune di esse.

Sintetizzando, la corsa alle frequenze nasce dall’esigenza di aumentare il parallelismo interno dei chip: la prima strada intrapresa a tal fine, è stata quella di frammentare gli stadi di una pipeline, aumentando il numero di blocchi in grado di eseguire la stessa istruzione. In figura, il confronto tra la pipeline del pentium III e quella del pentium 4 willamette:

architetture-netburst.jpg

Come si vede nello schema, la pipeline del P4 ha il doppio degli stadi di quella del PIII e gli stadi sono di dimensioni notevolmente inferiori. La riduzione delle dimensioni degli stadi ha come conseguenze la frammentazione delle istruzioni e la riduzione del ciclo della singola istruzione. Nelle due immagini successive, sono poste a confronto un’architettura di tipo pipelined ed una di tipo superpipelined.

architettura-pipleined-cicli-e-istruzioni.jpg

architettura-superpipleined-cicli-e-istruzioni.jpg

Come si può vedere, nel secondo caso la durata del ciclo relativo alla singola istruzione è decisamente più breve e nello stesso intervallo di tempo necessario a inizializzare una istruzione in un’architettura di tipo pipelined, si ha la possibilità di inizializzarne più di una (3 nell’esempio) in un’architettura superpipelined.

Con l’avvento del core Prescott, gli stadi furono portati a 31, raggiungendo il massimo per l’architettura netburst.

Questo tipo di soluzione comporta una serie di problemi, gran parte dei quali elencati negli articoli linkati in precedenza. In particolare, introduce delle criticità sui dati, con stalli più frequenti, sul controllo, con un maggior numero di stadi su cui annullare l’esecuzione, sulla gestione della dissipazione termica e della potenza richiesta. Nella successiva figura, è riportato l’andamento del rapporto tra frequenza e potenza dissipata, per una cpu della serie opteron64, per variazioni di frequenza con step pari a 200 MHz

rapporto-tra-frequenza-e-potenza-dissipata.jpg

Come si vede, è sufficiente una diminuzione di 400 MHz di frequenza sul core per avere un quasi dimezzamento della potenza dissipata.

Da tener presente che ad ogni aumento di circa l’1% di performance, corrisponde un incremento pari a circa il 2-3% di potenza da dissipare e che, mediamente, la potenza di leakage subisce un incremento del 500% tra due scaling di tipo full node.

Queste considerazioni portano  al risultato che un Athlon fx62 (2800 MHz), a parità di processo produttivo, dissipa circa il doppio della potenza del singolo core di un Athlon X2 4800+ (2400 MHz) con prestazioni complessive mediamente inferiori del 20%.

Interessante, per terminare con le considerazioni sul rapporto tra performance per watt, dare un’occhiata a questo grafico (fonte AMD) sul suddetto rapporto relativamente a single, dual e quad core

confronto-single-vs-dual-vs-quad.jpg

Dalle considerazioni sin qui fatte e dai grafici mostrati, risulta evidente come quella del multicore sia una scelta dettata, tra le altre motivazioni, dal tentativo di ovviare all’inconveniente del continuo aumento delle frequenze con relativa impennata delle potenze e conseguente insorgere  di problemi legati a fenomeni parassiti indotti da temperature e correnti in gioco. La costante ricerca del parallelismo spinge, dunque, a migrare dalle architetture superpipelined a quelle di tipo superscalare, VLIW o SMT, che avessero la capacità di inizializzare più istruzioni o di avviare più thread in parallelo.

Nel campo delle GPU, abbiamo visto che l’evoluzione ha subito condotto verso architetture di tipo SIMD; per le CPU, invece, le cose sono andate in maniera differente, in quanto un’architettura SIMD non è ottimale per un impiego di tipo general purpose, in cui, al parallelismo dei dati si privilegia quello delle istruzioni.

Un’architettura MIMD di tipo single core risulterebbe estremamente complessa a livello progettuale e comporterebbe linee di trasmissione eccessivamente lunghe. Al contrario, la scelta di dividere una singola unità in tante unità più piccole, permette di semplificare notevolmente il layout del chip, di ridurre drasticamente la lunghezza delle linee di trasmissione e di spostare la complessità dal progetto singolo core a quello del sistema di comunicazione e di bilanciamento dei carichi tra i vari core. Infine, nel complesso, anche nelle applicazioni che richiedono parallelismo dei dati, un’architettura MIMD di tipo multicore risulta, complessivamente, più efficiente di una superscalare o di una SMT di tipo single core, come mostra il grafico seguente:

multocore-vs-superscalare-vs-smt.jpg

Quindi, la scelta del multicore è dettata da questioni di carattere “energetico”, da una maggiore efficienza assoluta e relativa, qualora si faccia una comparazione delle performance per watt, e dalla necessità di semplificare la fase di progettazione e di testing di chip che stanno diventando sempre più complessi.

I vantaggi delle architetture multicore, però, non si esauriscono qui: sempre sul piano energetico, avendo a disposizione più core indipendenti risulta più semplice decidere di spegnere parte del processore non utilizzato da quella particolare  applicazione. Spegnere uno o più core è più facile che fare la stessa cosa con i circuiti interni di un chip ricorrendo a meccanismi di clock gating.

Infine, finora abbiamo considerato l’ipotesi di core di tipo simmetrico, ma un’architettura multicore può anche essere pensata con core asimmetrici, ognuno dei quali dedicato ad un particolare compito. In tal caso,i vantaggi, sia dal punto di vista delle prestazioni che dell’efficienza energetica, possono addirittura aumentare.

Infine una breve considerazione su multicore vs multichip; tra le due, il vero vantaggio della prima è, ancora una volta relativo al risparmio energetico:  ormai, circa il 35-40% della potenza dissipata da un chip, è impiegata per le operazioni di I/O ed avere un singolo processore con un unico circuito di I/O, permette di avere vantaggi non indifferenti dal punto di vista del risparmio.

Ora che abbiamo visto il motivo che sta alla base della scelta delle architetture multicore, vediamo brevemente cosa è opportuno integrare e cosa è meglio lasciare fuori.

L’integrazione del memory controller, permette di ridurre le latenze relative agli accessi alla memoria e riduce la necessità di avere cache di grandi dimensioni. Abbinato al MC, conviene integrare un ring o un crossbar switch che permetta la connessione dei vari core e un qualsiasi link a dispositivi ad elevato transfer rate (come il canale dedicato alle comunicazioni tra due GPU, oppure bus come l’hyperstransport di AMD, ad esempio).

Il prossimo passo sarà quello di integrare funzioni grafiche o, per meglio dire un intero core grafico, creando, di fatto, una soluzione multicore di tipo asimmetrico. Quindi, quello che conviene integrare è tutto ciò che necessità di elevati valori di transfer rate (elementi atti a gestire e permettere la comunicazione con la ram con gli altri core e con un eventuale chip grafico), mentre è opportuno lasciar fuori tutto il resto, per evitare di intasare inutilmente i canali di comunicazione interni al chip.

Ovviamente, anche le architetture multicore presentano delle criticità tra cui, ad esempio, il northbridge che può costituire un collo di bottiglia se non si bilanciano in maniera corretta il numero di core con il numero e le dimensioni delle cache interne al chip e se non si programma opportunamente il MC. Questo perché la ram è il canale di I/O sono due degli elementi contesi tra tutti i possibili utilizzatori, ovvero i core del processore e l’accesso ad essi deve essere gestito in maniera tale da evitare o minimizzare ogni eventuale “ingorgo” che comporti tempi lunghi di attesa.

Una delle strade che si percorrono per ridurre l’impatto delle latenze di determinate operazioni è quella del multithreading. In effetti, prima ho presentato le architetture multicore e quelle SMT come se fossero concorrenti: di fatto non è così ed è sempre più frequente assistere alla presentazione di architetture multicore e multithreaded.

Un altro dei limiti delle architetture multicore è che, per risultare veramente efficienti in tutti i campi, hanno bisogno del supporto del sistema operativo e del software che devono elaborare. E questo vale tanto più per le architetture in cui il bilanciamento dei carichi di lavoro non avviene in hardware.

Oggi abbiamo visto, principalmente, perché si è scelto di battere la strada del multicore e se ne sono visti, soprattutto, i vantaggi mentre si è fatto solo qualche cenno alle problematiche connesse alla progettazione ed alla realizzazione di un chip multicore. In futuro torneremo su questi aspetti molti dei quali sono comuni anche alle architetture dei chip grafici che rappresentano l’argomento principale di questa rubrica.

Se nel campo delle CPU la scelta del multicore appare inequivocabile, in ambito GPU pare esserci una maggiore ambiguità; se è possibile, ad esempio, definire larrabee un chip multicore o, per meglio dire, per usare la definizione di Intel, “manycore”, si può dire lo stesso, ad esempio, di GT200 o di RV770?

Abbiamo visto che le cpu multicore presentano architetture MIMD con memoria cache a più livelli, in parte dedicata ed in parte condivisa. Anche i chip grafici sopra elencati presentano blocchi di unità di calcolo gestiti in modalità MIMD e, quindi, almeno in parte, l’analogia è possibile.

Certo, non si tratta di core fisicamente distinti, non sono gestiti singolarmente ma in blocco da un unico thread processor principale e neppure si può pensare di ricavarne un’architettura di tipo asimmetrico. Si potrebbero, con buona approssimazione, considerare delle architetture “ibride” con caratteristiche tipiche, vantaggi e problemi connessi alle architetture multicore di cui condividono, almeno in parte, l’impostazione.

79 Commenti »

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.

  • # 1
    n0v0
     scrive: 

    io ho un quad core… ma lo vorrei veder sfruttato!!

    uso linux (ubuntu) e raramente ho visto impegnati tutti e 4 i core nel fare qualcosa, tipo video editing, gimp, calc…

    sembra che il SO sfrutti i core multipli NON dividendo il lavoro per 4 ma moltiplicando per 4 i lavori possibili allo stesso tempo (uno per core).

    però io non voglio fare 4 lavori alla stessa velocità di un single core, ma un solo lavolo 4 volte più rapido!!

    chi glielo va a spiegare?

  • # 2
    massimo m.
     scrive: 

    se il programma non e’ multithread, non si puo’ fare nulla. non e’ un problema di linux, un thread solo non puo’ essere spezzato su piu’ core.

  • # 3
    n0v0
     scrive: 

    ho detto linux ma intendevo il software in genere

    cioè:
    i supercomputer esistono da decenni
    gli Xeon DP per workstation esistono dal 2001
    il primo dualcore domestico è arrivato nel 2005

    che aspettano a fare tutto in parallelo?

  • # 4
    floc
     scrive: 

    e diciamo anche che l’utente medio di + di 2 core non se ne fa nulla, x questo nemmeno su linux li vede sfruttati. Io lavoro con 4-5 macchine virtuali aperte alla volta, vi assicuro che li sfrutto e mi servono tutti e 8 i miei core anche sul pc di casa ma e’ uno scenario decisamente di nicchia… Ok comprare un quad core per il futuro, ma ha senso andare oltre?

    diciamo che i multicore sono NATI per necessita’, e si sono diffusi per MODA visto che dopo la corsa al ghz dovevano trovare qsa per infinocchiare l’utente medio :)

  • # 5
    v1
     scrive: 

    grazie, ottimo articolo

  • # 6
    Maruga
     scrive: 

    Articolo molto interessante. E’ ovvio che per ora l’utente medio, per medio intendo la persona che usa il pc per giocare navigare e poco altro, non si avvantaggi un granchè della tecnologia multi-core. Tuttavia in ambito professionale è una manna scesa dal cielo.
    Io personalmente faccio editing video e compositing e da quando sono usciti i multi core il mio lavoro ha preso un’impennata pazzesca, in termini di resa e quindi anche di qualità, visto che se impiego all’incirca un ottavo del tempo (in ufficio uso un octo core xeon) per fare un rendering avrò più tempo per perfezionare il risultato.
    Applicazioni come la suite Adobe, Final Cut, codificatori video/audio usano il multi core come pane ai poveri…

  • # 7
    die81
     scrive: 

    @ FLOC

    hai ragione fino a un certo punto…vuoi forse dire che in futuro non servirà piu potenza?

    il multi core è l unica risposta possibile…la tecnologia hardware c’è…ora serve il software

  • # 8
    Andrea R
     scrive: 

    due core sono utili: uno per il programma usato e uno per i servizi in background.
    Con due core non scatta mai un film o compiz, il sistema è più reattivo.

    Ma 4 core non servono, al giorno d’oggi sul desktop.

  • # 9
    pleg
     scrive: 

    > che aspettano a fare tutto in parallelo?

    Non e’ facile :) Ci sono gruppi di ricerca in tutte le universita’ e in tutte le aziende (sia HW che SW) che stanno cercando di risolvere il problema, ma e’ molto difficile. Certe cose si parallelizzano facilmente, altre meno… per altre e’ impossibile. E soprattutto, e’ difficile farle scalare: magari far andare un’applicazione su due core e’ fattibile, ma su 100? 1000? Nessuno sa ancora come si fa. Chi lo scopre diventa ricco e famoso :))

    > diciamo che i multicore sono NATI per necessita’, e si sono diffusi per MODA visto che dopo la corsa al ghz dovevano trovare qsa per infinocchiare l’utente medio :)

    Diciamo anche che e’ l’unico modo che ci e’ rimasto per continuare ad aumentare le prestazioni. Frequenza, ILP e tensione hanno praticamente smesso di scalare; l’unica cosa che continua ad andare, incredibilmente, e’ la legge di Moore, e l’unico modo che si conosce per spendere quei miliardi di transistor e’ di mettere piu’ core in un chip.
    Piacerebbe a tutti continuare col trend precedente, piu’ prestazioni su un singolo core, ma nessuno sa piu’ come fare.

  • # 10
    Anonymous
     scrive: 

    Ma invece di fare CPU multicore, ora che siamo a 32nm non sarebbe meglio farne una singlecore? dovrebbero starci 1 miliardo di transistor con quel processo produttivo (anche nel caso di un ipotetico quad-core)
    Non sarebbe forse più veloce di un quad? (tanendoli alla stessa frequenza).
    Cioè voglio dire, invece di fare 4/8 core piccolini perchè non se ne fa uno unico grande? si eviterebbero tutti i problemi delle CPU multicore.
    Scusate se ho detto qualche cavolata, cerco solo di capire.
    Grazie dell’ottimo articolo anche se sinceramente ci capisco poco.

  • # 11
    filippo1974
     scrive: 

    A completamento di quanto detto da pleg, aggiungerei che ci sono ambiti applicativi per i quali la parallelizzazione, quand’anche fosse possibile, non è detto che sia così pressante da implementare, perché i colli di bottiglia sono altrove. Mi riferisco, in generale, a tutte quelle applicazioni nelle quali la macchina passa gran parte del tempo ad attendere l’input dell’utente (ad esempio, un word processor: a che giova farlo multi-threaded se poi è la velocità -o la lentezza LOL- dell’operatore umano che determina in massima parte la produttività?)

    Comunque il multi-core resta una strada assolutamente importante da perseguire. Il parallelismo, anche se non si riesce ad ottenere sempre a livello di singola applicazione (multi-threading) è comunque ormai un fatto assodato a livello di più applicazioni concorrenti (multi-tasking), e in questo caso il multi-core ti dà un aiuto “gratis”.

  • # 12
    Gurzo2007
     scrive: 

    @Anonymous

    praticamente no…a parità di architettura e di ghz…2,3,4 è meglio di 1…ovvio ke se un programma è mono thread, ke tu abbia 1 o 1000core il programma va uguale…ma prova a far andare contemporaneamente 100 programmi su un single core e su un dual core…noterai una notevole differenza di prontezza del sistema nel secondo caso

    poi ovvio tutto dipende dai casi…ci sono programmi ke si avvantaggiano ancora nell’avere moti ghz…altri di avere nmila core…tutto dipende dall’utilizzo…ma ormai la base di partenza sono i dual core…con cui ci fai tutto e non hai mai problemi…

    io ho un pc single core…e molto volte si sente la mancanza almeno del secondo core

  • # 13
    pabloski
     scrive: 

    c’ero cascato :D il titolo mi aveva tratto in inganno

    comunque è chiaro come il sole che il multicore non è moda ma è una necessità reale, del resto pare che le gpu l’abbiano dimostrato incontrovertibilmente

    il parallelismo è l’unica strada per aumentare le prestazioni

    riguardo la necessità in relazione all’utente comune vorrei dissentire….è vero che oggi l’utonto ( chiamiamolo così ) usa solo il browser per vedere i pornazzi, ma è pur vero che da qui a poco diventeranno realtà interfaccia grafiche 3d, sintesi e riconoscimento vocale e tutte queste applicazioni necessitano di molta potenza

    è vero che ad oggi i sistemi di riconoscimento vocale fanno ridere, però la tecnologia avanza abbastanza velocemente e presto arriverà il prodotto finale e realmente utilizzabile dalla massa

  • # 14
    Massimo
     scrive: 

    Una cosa miè poco chiara: Ok per programmi multitask, ne scrivo anche io (ancher se banali …) ma è il S.O. che gestisce più programmi in parallelo ed assegna la(le) CPU come una risposra.
    Se io (volessi) urtilizzare 3 programmi single core sarà il S.O. ad asseganre un core per ciascuno, così come adesso ne assegna uno per il time sharing.
    Realizzare UN singolo rogramma che utilizzi tutti i core a disposizioneè estremamente complicato anche perchè non è sempre facile sapere:
    Quanti core ha il customer
    Bilanciare il carico esattamente: se questo è dinazmico non risco a fare previsioni.
    Questo è il mio problema (al alvoro), ma troppo spesso sento parlare di programmi e programmi .. Ma il più lo fa (lo può fare) anche il S.O. !

  • # 15
    Gurzo2007
     scrive: 

    @pabloski

    ehm direi ke per le interfaccie grafiche ci sarebbero anke le sk grafiche…alla fine per l’utonto medio un dual core anke in futuro basta e avanza..a meno di non parallelizzare anke il blocco note :asd:

    già oggi con 50-80processi(soprattutto sui notebook) attivi in background il dual core è quasi inutilizzato…a meno di non usare programmi pesanti anke in futuro…mi sembra difficile per l’utenza media arrivare a sfruttare a dovere quad o octocore

    ps non mi sembra ke per il riconoscimento vocale ci voglia molta potenza…usavo i comandi vocali per il pc ai tempi del pentium mmx tramite un programma ibm :)

    @Massimo
    ovvio ke la gestione dei programmi è affidata al SO…ma se un programma non è multithread…come fa il SO ad assegnare i vari thread ai vari core?
    ma ovviamente deve anke essere il programma ad avvantaggiarsi della programmazione in multithread…e come si vede oggi, non tutto si avvantaggia di questo tipo di programmazione…in futuro forse sarà diverso o almeno si spera

  • # 16
    biffuz
     scrive: 

    Il multicore sarà anche interessante, ma entro certi limiti.

    Posso presentare come esempio gli attuali UltraSparc T1 e T2 con 32 e 64 thread, dove però i singoli thread sono più lenti che nei precedenti modelli. Dove lavoro non sono esattamente felici dell’acquisto: le applicazioni sono scarsamente parallellizzabili – più che altro interrogazioni su DB e generazione di pagine con i dati estratti – e il risultato è che i tempi di attesa per gli utenti sono più alti rispetto ai server vecchi. Servirebbero migliaia di utenti in più per raggiungere la parità dei tempi.

    Qualcuno ha suggerito di rispedire a Sun i suoi “baracconi” e prendersi degli Xeon.

    Dopotutto se la Sun ha cancellato i progetti per il nuovo RK, che procedeva su questo concetto, un motivo ci sarà…

  • # 17
    chojin999
     scrive: 

    A parte l’articolo che mischia concetti e termini in maniera confusionaria, tanto è che le architetture pipeline e superscalar non c’entrano nulla con multi-core ed SMP… (per la cronaca la prossima architettura Tera-scale di Intel per CPU multi-core così come anche Larrabee, i due progetti sono stati sviluppati in parallelo e collegati fra loro per vari aspetti, prevedono la possibilità di avere core anche non x86 specializzati, come ad esempio dei core dedicati all’esecuzione accelerata di codice di macchine virtuali Java e .NET, core dedicati all’accelerazione floating point e così via..)
    Ma poi i commenti all’articolo che si leggono… ma avete qualche idea di cosa state parlando? A me sembra proprio di no.
    Quello che afferma che non vi sarebbe modo di parallelizzare algoritmi su 1000 processori… mai sentito parlare di cluster? Il rendering 3D per la CGI dei film come pensate che funzioni? Il calcolo scientifico viene distribuito da anni sui supercomputer le cui sottounità da centinaia di CPU per rack sono collegate ad altissima banda in rete in fibra ottica…
    La ricerca di cui parlate è per semplificare ai programmatori la vita, non per rendere possibile la parallelizzazione degli algoritmi! Il renderli parallelizzabili è estremamente complesso perchè per avere un’architettura multi-thread dei programmi bisogna scriversi i propri thread scheduler, gli scheduler degli OS non gestiscono direttamente i thread ma solo i processi, sta al programmatore poi progettare il proprio scheduler per gestire i thread e non è per nulla semplice–il che non significa che non ne esistano ad alta efficienza da tempo…
    La ricerca nell’industria sta quindi cercando, attraverso accordi fra i produttori, di creare uno standard per i linguaggi di programmazione tramite estensioni a C++, Java ed agli altri per consentire ai programmatori di programmare in multithread senza bisogno di scriversi un proprio thread scheduler, in maniera totalmente trasparente così che i compilatori possano poi generare il codice in maniera opportuna.

  • # 18
    yossarian (Autore del post)
     scrive: 

    @ biffuz
    non so di cosa si occupi la società per cui lavori e che tipo di applicazioni usiate, però processori come gli ultrasparc della serie T1 e T2 sono indicati per applicazioni in cui il numero di thread supera quello dei core fisici (i T1 hanno 8 core e 4 thread per core e i T2 8 core e 8 thread per core) e più è elevato il rapporto tra numero di thread e numero di core, più si avvantaggia quel tipo di architettura. In caso contrario, il loro utilizzo è controproducente. Quindi l’errore è stato nella scelta di quel tipo di cpu.

    @ chojin999
    1) architetture superscalari, VLIW, SMT o EPIC nascono per lo stesso scopo delle SMP o delle multicore, anche se si basano su principi architetturali parzialmente differenti. GT200, secondo te, può essere considerato un’architettura multicore? Analogie e differenze tra SMP ed SMT?
    Per la cronaca, le pipeline non sono un aspetto caratterizzante delle architetture x86; l’architetutra PowerPC è a pipeline e non è x86, l’architettura sparc è a pipeline e non è x86, l’architettura di qualsiasi chip grafico è a pipeline e non è x86. L’architetutra di larrabee è a pipeline, come lo è Itanium e lo saranno le cpu che usciranno dal progetto terascale. Per la cronaca, proprio larrabee ha core con una pipeline con 16 alu scalari; pipeline di quel tipo, a seconda di come sono organizzate, possono essere o vettoriali, o superscalari o vliw oppure epic.
    Dove sarebbe la confusione?
    2) Il rendering 3D viene fatto da chip grafici e non da cpu e all’interno di un chip grafico, anche con architettura SMT (come GT200 o RV770), in linea di principio riconducibile, come funzionamento, a delle architetture multicore, il bilanciamento dei carichi di lavoro e, nel caso di chip superscalari, anche le operazioni di scheduling, sono gestiti in hardware e, in tal caso, si tratta di processi quasi trasparenti al codice da elaborare.

  • # 19
    chojin999
     scrive: 

    @18,yossarian: la risposta che ha dato all’utente “biffuz” sugli Ultrasparc evidenzia che lei non ha la minima di idea del funzionamento di SMP, NUMA ed architetture multi-core nè ha la comprensione del meccanismo dei thread. Ciò che ha scritto lì in risposta è veramente una stupidaggine, glielo dico sinceramente. Non sa di cosa sta parlando. E’ inutile discutere di altri aspetti se a lei mancano le basi teoriche per comprendere la pratica di funzionamento delle architetture ed i relativi meccanismi di programmazione degli algoritmi.

  • # 20
    chojin999
     scrive: 

    Questo documento spero possa essere utile come riassunto dei concetti alla base di SMP, SMT, multi-threading, scheduling che l’OS deve comunque sempre gestire (no, non funziona tutto trasparente in hardware come pensa lei):

    ———
    http://www.cs.uiuc.edu/class/sp05/cs523/prev_exams/2004spring/midterm/neelakan/index.html

    Introduction

    Parallel computer systems provide increased performance for applications that can be parallelized and increased throughput for concurrent jobs. One approach to building parallel systems is to connect logically independent machines using a high-speed interconnect. Communication between related processes on these systems occurs either over the interconnect via a message-passing protocol (such as MPI) or through hardware supported shared memory (CC-NUMA). However, the relatively high cost of communicating with a process running on a remote machine limits parallel applications to course-grain parallelism. In addition the cost of purchasing many machines connected by an often expensive custom interconnect further limits the deployment of these systems.

    An alternative approach is to build a parallel system out of a single machine that contains several processors (called a Symmetric Multi-Processor or SMP). Because each processor resides in the same machine as its peers, interprocess communication can take place through shared-memory. This greatly reduces the communication costs and enables applications to exploit much finer-grain parallelism. The cost of an SMP is also much cheaper and as a result they have gained a much wider acceptance. However, the existence of several processors within a single machine introduces several new variables to the problem of processor scheduling and is the focus of this survey.

    The Operating System (OS) is typically the entity responsible for making processor scheduling decisions. It must decide how to allocate available processor resources to processes from contending applications (the problem is somewhat simplified if the OS is not multiprogrammed but we ignore this trivialization). The OS must decide how many processors to allocate to a particular application and how to map application processes (aka. threads) to these processors. Poor scheduling decisions can dramatically reduce the overall throughput of the system as well as increase the running time of individual processes, and therefore effective processor scheduling is essential to the overall performance of an SMP.

    Multiprocessor Scheduling

    There are several types of policy decisions that an OS must make when considering multiprocessor scheduling. The OS must decide whether to partition the available processors among competing processes and whether or not the partitioning is allowed to change dynamically. It must choose between a global scheduling queue shared by all processors and local per-processor scheduling queues. The OS also determines whether or not the system is preemptive.

    By subdividing the available processors into partitions containing one or more processors, the OS can choose different policy decisions for each partition [3]. For instance, one partition (containing a single processor) could be reserved for single-threaded applications and a second partition (containing the remaining processors) could be reserved for multi-threaded applications. Alternatively, one partition could provide First Come First Serve (FCFS) non-preemptive scheduling while another provides Round Robin (RR) preemptive scheduling. Processes could then be scheduled to the partition best suiting their application characteristics and needs. The precise design space for partitioning is extensive and is beyond the scope of this survey, but in general it provides OS designers with a high degree of flexibility in the design of the OS scheduler.

    If partitioning is used, the OS must choose whether to allocate processes to partitions statically [6] or dynamically [8]. A static partition reduces OS overhead and works well with applications that cannot adjust their level of concurrency at runtime. However, the OS is restricted from reorganizing partitions to meet changing application demands. With a dynamic partition the OS is free to reorganize the machine at will but requires careful bookkeeping (partitions being modified must have their processes quiesced) and may adversely effect the running time of applications that cannot change their level of concurrency dynamically. This is especially true for parallel applications with tight synchronization: if more threads exists than processors allocated, a thread holding a lock may be unscheduled and prevent any other threads from making forward progress [8]. However for applications that are capable of changing their level of concurrency to adapt to changes in processor allocation, overall system throughput and individual application performance can be improved. This is due to the fact that most parallel applications scale sub-linearly with increasing concurrency, and by dynamically reducing the number of processors allocated to each application (in order to accommodate additional applications) the OS can provide more efficient processor utilization.

    The OS can choose to organize runnable processes either using per-processor (local) queues or in a single global queue shared for all processors. In the local queue organization each processor has an associated queue of runnable processes and whenever the processor becomes idle it swaps in the process at the head of the queue. Local queues provide the OS with the ability to map a process onto a specific processor in order to provide processor-cache reuse. On the other hand, local queues can introduce load-balancing problems because one processor may quickly empty its queue and become idle while other processors are still occupied. In the global queue organization, all processors share a single queue and when any processor becomes idle it swaps in the process at the head of the queue [3]. This inherently provides effective load-balancing because all processes contend for all the processors, but means that a process may be scheduled onto a different processor each time it is executed. This tends to reduce application performance because processes thrash each processor’s cache as they cycle around. Affinity scheduling [7] can be provided by the OS to counteract this problem: the OS can prejudiciously schedule processes from the global queue such that a process tends to stay on the same processor.

    Tightly synchronized parallel applications pose an interesting problem for multiprocessor scheduling. These types of applications tend to use a number of processes to execute parallel regions of code ending with barrier synchronization. If any one of the processes is not scheduled during the parallel region, the rest of the processes will spin wait (after reaching the barrier) until the lagging process is scheduled and arrives at the barrier. However, from the point of view of the OS a spinning process is indistinguishable from performing useful computation. Thus the spinning processes will continue to be scheduled and will reduce the overall throughput of the system [7]. The OS can solve this problem by allowing parallel applications to request gang scheduling [5]. With gang scheduling either all the processes of an application are scheduled or none are scheduled. It should be noted that an alternate solution can be implemented by the application by using two-phase synchronization where a process spins for a while at the barrier (or lock) and then suspends if it still has not passed the barrier (or acquired the lock) [1].

    Most SMP operating systems are multitasked and use preemptive time-sharing for all processes. While this is desirable in the general case (because of fairness, asynchronous I/O and improved response times) some operating systems may opt for a non-preemptive model. Hard real-time systems are an example of a situation where an OS may choose a non-preemptive implementation in order to simply reasoning about deadlines. Such operating systems may use application provided timing information to find a pre-run-time schedule that meets all deadlines [10].

    Recent Directions

    An emerging hardware technology has posed new problems for SMP operating systems. Simultaneous Multi-Threading (SMT) enables a single processor to simultaneously execute multiple processes by allowing each processor to execute multiple process-contexts (SMT-context). All processes running on the SMT processor implicitly share the internal hardware resources of the processor. As a result, each application’s performance decreases slightly but overall system throughput increases (because internal processor resources are better utilized) [9]. Hardware implementing SMT (such as Intel’s Pentium 4 with Hyperthreading) expose this functionality to the OS by making each SMT-context logically appear as a separate processor.

    This is problematic on SMP machines built out of SMT processors. Unless the OS is careful, logical processors (SMT context) will be indistinguishable from actual physical processors from the point of view of the scheduler. To illustrate the problem, consider a scenario where a two-processor SMP machine is built using two-way SMT processors. To the OS scheduler the machine appears to be a four-way SMP, and processes contend for one of the four available logical processors non-preferentially (assuming a global queue). Supposing only two processes are runnable, there are two possible scheduling outcomes: either each process executes on a separate physical processor or both processes execute on the same physical processor (but on separate logical processors). If both processes are scheduled onto the same physical processor, they will effectively slow one another down and injure system throughput while the other physical processor sits idle. Instead, the scheduler should recognize the difference between logical and physical processors and schedule the processes appropriately (ie. onto different physical processors) [4].

    Another change to OS scheduling has occurred because of a growing acceptance of unline-profiling in system design. For example, a new scheduling approach has been proposed recently that enables feedback-directed processor allocation [2]. Conventional scheduling mechanisms simply trust that an application can efficiently utilize the number of processors that it has requested. However, some other application may be running that exhibits better scaling properties and would better benefit from more processors. The recent work proposes to provide library routines to applications that enable them to calculate the parallel speedups they can attain for a varying numbers of processors. By analyzing this information the OS can make informed decisions for processor allocation. Rather than allocating all processors equally among parallel applications, the OS can prejudiciously allocate processors such that overall system throughput is increased

    Conclusion

    An SMP-capable OS must consider a wide degree of options in order to implement an effective set of scheduling policies. Many of the decisions are workload dependent, and thus OS designers must carefully consider the types of applications that will run on the system when implementing the scheduler. Failing to take workload and hardware details into account will generally result in a scheduler that is single-handedly responsible for poor system performance. Therefore it is of the utmost importance that the scheduler be implemented in a fashion that is amenable to the expected application workload. As workloads change and new hardware features emerge, old scheduling implementations will likely need to be revisited in order reevaluate policy decisions.
    ——-

  • # 21
    filippo1974
     scrive: 

    @ chojin999

    In un tuo intervento hai scritto:

    “… per avere un’architettura multi-thread dei programmi bisogna scriversi i propri thread scheduler, gli scheduler degli OS non gestiscono direttamente i thread ma solo i processi…”

    Dopodiché hai linkato a supporto delle tue affermazioni un documento dove si dice:

    “The OS must decide how many processors to allocate to a particular application and how to map application processes (aka. threads) to these processors…”

    Quindi è necessario o no che uno sviluppatore si scriva il proprio thread scheduler? A me risulta che sotto Windows ciò sia vero solamente se si usano i Fibers. Ma potrei sbagliarmi.

    Ciao
    Filippo

  • # 22
    chojin999
     scrive: 

    @filippo1974: dipende dalle architetture degli OS il come vengono gestiti i thread. Alcune implementazioni di OS hanno scheduler che gestiscono anche i thread e non solo i processi, ma solitamente ciò è vero per i thread dei processi che girano nel livello del kernel. Questo documento spiega gli approcci in UNIX di tipo ULT e KLT, le differenze di base e l’uso combinato dei due tipi di thread:

    —–

    http://www.cs.cf.ac.uk/Dave/C/node29.html#SECTION002921000000000000000

    Thread Levels

    There are two broad categories of thread implementation:

    * User-Level Threads — Thread Libraries.
    * Kernel-level Threads — System Calls.

    There are merits to both, in fact some OSs allow access to both levels (e.g. Solaris).

    User-Level Threads (ULT)

    In this level, the kernel is not aware of the existence of threads — All thread management is done by the application by using a thread library. Thread switching does not require kernel mode privileges (no mode switch) and scheduling is application specific

    Kernel activity for ULTs:

    * The kernel is not aware of thread activity but it is still managing process activity
    * When a thread makes a system call, the whole process will be blocked but for the thread library that thread is still in the running state
    * So thread states are independent of process states

    Advantages and inconveniences of ULT

    Advantages:

    * Thread switching does not involve the kernel — no mode switching
    * Scheduling can be application specific — choose the best algorithm.
    * ULTs can run on any OS — Only needs a thread library

    Disadvantages:

    * Most system calls are blocking and the kernel blocks processes — So all threads within the process will be blocked
    * The kernel can only assign processes to processors — Two threads within the same process cannot run simultaneously on two processors

    Kernel-Level Threads (KLT)
    In this level, All thread management is done by kernel No thread library but an API (system calls) to the kernel thread facility exists. The kernel maintains context information for the process and the threads, switching between threads requires the kernel Scheduling is performed on a thread basis.

    Advantages and inconveniences of KLT

    Advantages

    * the kernel can simultaneously schedule many threads of the same process on many processors blocking is done on a thread level
    * kernel routines can be multithreaded

    Disadvantages:

    * thread switching within the same process involves the kernel, e.g if we have 2 mode switches per thread switch this results in a significant slow down.

    Combined ULT/KLT Approaches

    Idea is to combine the best of both approaches

    Solaris is an example of an OS that combines both ULT and KLT (Figure 28.4:

    * Thread creation done in the user space
    * Bulk of scheduling and synchronization of threads done in the user space
    * The programmer may adjust the number of KLTs
    * Process includes the user’s address space, stack, and process control block
    * User-level threads (threads library) invisible to the OS are the interface for application parallelism
    * Kernel threads the unit that can be dispatched on a processor
    * Lightweight processes (LWP) each LWP supports one or more ULTs and maps to exactly one KLT

    Threads libraries

    The interface to multithreading support is through a subroutine library, libpthread for POSIX threads, and libthread for Solaris threads. They both contain code for:

    * creating and destroying threads
    * passing messages and data between threads
    * scheduling thread execution
    * saving and restoring thread contexts

    ——-

  • # 23
    filippo1974
     scrive: 

    Ti ringrazio per il contributo che proverò a leggermi con calma (lo vedo piuttosto approfondito…)

    Per il resto ho paura che ci stiamo un po’ perdendo nei tecnicismi e quindi stiamo perdendo un po’ di vista il tema fondamentale, che è la convenienza o meno di percorrere la strada del multi-core.

    Io resto del parere che sì, questa è la strada, perché al di là delle giustificazioni tecniche mi sembra che l’utilità di questa scelta sia sotto gli occhi di tutti, anche nel settore consumer.

    Ciao
    Filippo

  • # 24
    biffuz
     scrive: 

    La scelta (evidentemente sbagliata, ma la proposta è stata fatta da una persona che si supponeva competente) è stata fatta in base all’idea che il numero di utenti è abbastanza elevato, e che quindi questa architettura potesse portare dei benefici nei tempi di risposta: si tratta di server applicativi e di presentazione in una classica architettura 3-tier.

    Quello che è stato calcolato male è il tempo macchina delle singole richieste: in pratica il server deve solo confezionare le query da spedire al DB (su altri server) e presentare una bella paginetta web con i risultati; la maggior parte del tempo quindi la CPU lo passa ad aspettare la risposta dal DB. In questo tempo si può cambiare thread e gestire la richiesta di un altro utente.
    La scelta è sbagliata nel momento in cui il numero di utenti non è tale da giustificare un aumento del numero di thread gestibili dalla CPU a scapito della velocità del singolo.

    L’idea è quindi di tornare a sistemi più veloci sul singolo thread, e tra gli attuali Sparc e gli Xeon questi ultimi danno la polvere ai primi.

    Visto che l’azienda per cui lavoro opera in uno dei settori economicamente più importanti per i produttori di server e DB, e che la sua dimensione è di tutto rispetto, è ovvio che la Sun si sia preoccupata…

  • # 25
    yossarian (Autore del post)
     scrive: 

    @ chojin999

    la risposta che ho dato all’utente biffuz è stata estrapolata dalla documentazione relativa alle cpu ultrasparc T1 e T2. Inoltre, l’ulteriore chiarimento da parte di biffuz conferma quanto da me scritto. Cito, inoltre, da l documento da lei stesso linkato e riportato All processes running on the SMT processor implicitly share the internal hardware resources of the processor. As a result, each application’s performance decreases slightly but overall system throughput increases (because internal processor resources are better utilized) [9]. Gli ultrasparc T1 e T2 sono multithreaded e, come riportato nel documento, a dire la verità, non molto approfondito, le performance della singola applicazione diminuiscono. Su una cpu multicore e multithreaded, questo discorso vale per ogni singolo core. Quindi, più è elevato il rapporto tra thread e core, più una cpu multithreaded è conveniente.

    In quanto al resto, è evidente che lei ha seri problemi con la lingua italiana in quanto ho esplicitamente parlato di rendering 3D e di chip grafici. Quindi il “quasi trasparente all’applicazione” non è riferito a generici sistemi di tipo SMP ma a qualcosa che lei dimostra di non conoscere affatto, ossia all’architettura di un chip grafico con particolare riferimento a quelli a shader unificati. Inoltre, il “codice da elaborare”, nello specifico, non è l’OS e neppure l’API di riferimento, fino a prova contraria.
    In quanto alla confusione da lei fatta su x86, pipeline, larrabee, ecc. stendiamo un velo pietoso.

  • # 26
    chojin999
     scrive: 

    @yossarian: dimostra di essere veramente puerile. Non solo cita pezzi in inglese di un documento senza comprendere il significato per tentare di darsi ragione, ma oltretutto con arroganza assoluta prende ed attacca insultando anzichè riconoscere di aver torto. Torni all’asilo che a quanto sembra non vi è stato abbastanza tempo e non ha potuto sfogarsi nelle diatribe fra bambini. E’ liberissimo di restare fiero della sua ignoranza degli argomenti e di continuare a scrivere sciocchezze, ma per favore eviti di attaccare ed insultare gli altri quando le fanno notare che ha detto delle stupidaggini.
    La sua reazione conferma solo che non è in grado di discutere seriamente da persona adulta di argomenti tecnici, e vorrei farle notare che la peggior cosa che si può fare nel settore IT è quello di essere arroganti, c’è sempre qualcosa che non si sa ed è evidente che lei non conosce le basi di ciò di cui parla. Posso capire che trovarsi uno che puntualizza i suoi errori possa averla irritata, tuttavia il suo comportamento resta puerile tanto quanto assurdo, se avesse risposto con pacatezza ed un pizzico di umiltà invece di attaccare avrebbe fatto una figura sicuramente migliore e non avrei dovuto perder tempo a rispondere ai suoi patetici attacchi da bambino dell’asilo.

  • # 27
    Cesare Di Mauro
     scrive: 

    Detto da uno che ha esordito con questo:

    “A parte l’articolo che mischia concetti e termini in maniera confusionaria
    […]
    Ma poi i commenti all’articolo che si leggono… ma avete qualche idea di cosa state parlando? A me sembra proprio di no.
    […]
    mai sentito parlare di cluster? Il rendering 3D per la CGI dei film come pensate che funzioni?”

    fa semplicemente ridere il vittimismo e i presunti “attacchi” di cui sarebbe stato oggetto.

    Ma soprattutto uno che scrive questo:

    “Quello che afferma che non vi sarebbe modo di parallelizzare algoritmi su 1000 processori… mai sentito parlare di cluster?”

    e poi continua con esempi di parallelizzazione cercando, quindi, di estendere alla totalità del calcolo tale possibilità, ignora del tutto il concetto di dipendenza dei dati, vero tallone d’Achille della parallelizzazione.

    Ma magari sarà in grado di spiegare in che modo si possa risolvere il problema della parallelizzazione dell’esecuzione dell’emulatore di un’architettura (esempio: un x86 che emula un 68000), anche su un paio di core e senza, quindi, necessariamente scomodare i ben più complessi e costosi cluster.

    Aspettiamo la risposta dell’esperto del “settore IT”…

  • # 28
    j
     scrive: 

    chojin999

    hai definito confusionario un articolo chiaro e pulito come pochi ancorchè tecnico,
    hai dato agli altri degli ignoranti dopo aver scritto delle emerite castronerie (*) riguardo i thread e lo scheduling da parte del sistema operativo (che peraltro non c’ entrava in questo contesto)
    hai tu per primo flooddato la sezione commenti con articoli in inglese non attinenti all’ argomento e che tu per primo hai dimostrato di non aver compreso
    hai tu per primo dimostrato un atteggiamento puerile ricorrendo agli argomenti ad personam appena ti si è fatto notare che eri in difetto…
    e hai il coraggio di definire puerile l’ autore dell’ articolo?

    (*) alle quali tra l’ altro stavo per rispondere punto a punto e pacatamente – ma dopo l’ ultimo post devo dire che rispondere sul piano tecnico a un troll del genere non vale assolutamente la pena

  • # 29
    j
     scrive: 

    filippo1974
    Quindi è necessario o no che uno sviluppatore si scriva il proprio thread scheduler? A me risulta che sotto Windows ciò sia vero solamente se si usano i Fibers. Ma potrei sbagliarmi.

    non sbagli ;)

  • # 30
    chojin999
     scrive: 

    @j: i documenti non c’entrano se non sai l’inglese e non sai leggerli. Negare la realtà è una forma di puerilità. Può non piacervi ma chiunque abbia una reale conoscenza degli argomenti potrebbe vedere senza problemi che non sono certo io ad avere detto stupidaggini. I documenti sono chiari e chi lavora davvero nel settore e programma sa di cosa si parla. Chi vuole far finta di essere esperto degli argomenti e sa solo insultare come risposta è ovvio che non possa prendersi la briga di studiare ciò che presume di sapere meglio del resto del mondo.

  • # 31
    Alessio Di Domizio
     scrive: 

    @ chojin999
    Da quel che leggo mi pare che nei toni il primo ad andare sopra le righe sia stato tu, e continui a farlo. Se adesso hai la pazienza di spiegare a chi ti ha posto delle questioni relative ai tuoi ragionamenti, in cosa cosa sbaglia, è bene, altrimenti di polemiche e attacchi personali preferiremmo fare a meno.

  • # 32
    Marco
     scrive: 

    @biffuz
    “la maggior parte del tempo quindi la CPU lo passa ad aspettare la risposta dal DB”

    E qui il problema non è certamente il T2.

    “La scelta è sbagliata nel momento in cui il numero di utenti non è tale da giustificare un aumento del numero di thread gestibili dalla CPU a scapito della velocità del singolo.”

    Ma allora perche’ l’avete comprato? Queste CPU sono efficienti solo quando ci sono n thread in esecuzione, e con 64 thread vantano un performance per watt ratio invidiabile.

    “è ovvio che la Sun si sia preoccupata”
    LOL
    Preoccupata di cosa? Che i loro clienti non sappiano scegliere la macchina adatta al tipo di workload?

  • # 33
    Marco
     scrive: 

    @chojin999
    Rispondi prima a Cesare, sono curioso anch’io di sentire la tua risposta.

  • # 34
    j
     scrive: 

    @filippo1974: dipende dalle architetture degli OS il come vengono gestiti i thread. Alcune implementazioni di OS hanno scheduler che gestiscono anche i thread e non solo i processi,

    in realtà gli os che supportano nativamente lo scheduling di threads sono la quasi totalità dei sistemi operativi, mainstream e non…

    ma solitamente ciò è vero per i thread dei processi che girano nel livello del kernel.

    dal contesto è chiaro che ti riferissi a quei sistemi in cui lo scheduler del kernel ha come unità base il thread e in cui quindi non è necessario un componente complementare lato applicativo – ma se parli di “processi che girano nel livello del kernel” parli di una cosa precisa, cioè di processi identificati dal loro stato (registri, stack, instruction pointer,..) che però sono caricati nello spazio di indirizzamento del kernel e accedono alle strutture dati interne al kernel senza context switch – in pratica di kernel thread

    Questo documento spiega gli approcci in UNIX di tipo ULT e KLT, le differenze di base e l’uso combinato dei due tipi di thread:
    [cut]

    di suo il “documento” non spiega granchè, ma semplicemente elenca tre diversi approcci concettuali per il design del thread scheduler ( peraltro limitandosi al solo ambito unix e tagliando via in un solo colpo alcune decine di sistemi operativi non meno interessanti, riconducibili a svariate famiglie ) senza appronfondire alcun dettaglio implementativo (quindi ugualmente superficiale di un ipotetico articolo sui sistemi operativi in cui si dica che esistono kernel monolitici e microkernel per fermarsi lì ..)
    inoltre tu lo strumentalizzi per avvalorare la tesi secondo cui sui sistemi con scheduler ibridi o multilivello sia necessario scrivere in proprio un thread scheduler perchè l’ OS non ne offre uno
    quando in realtà è implementato in un componente user space che opera di concerto con il kernel – seguendo un apposito meccanismo progettato da chi ha progettato il sistema operativo ( che ad esempio nel caso di freebsd 5 e 6 prevedava le KSE con relative upcall to userspace per il wakeup e select dei thread) ma esiste, eccome, e bypassarlo implicherebbe, oltre a doverne replicare le funzionalità per avere in cambio vantaggi minimi, voler dimostrare di “saperne di più” di chi ha realizzato il sistema operativo…

  • # 35
    pleg
     scrive: 

    L’utente chojin999 sembra un troll, non ci perderei molto tempo. L’articolo che ha postato (e gia’ qui: il link non bastava? Bisognava riportare pagine di roba sul forum? Direi proprio di no) e’ introduttivo (aka superficiale) e sembra anche vecchio: i riferimenti bibliografici si fermano al 2002, la maggior parte e’ degli anni ’90, e non vengono nemmeno menzionati i CMP! e visto che oggi tutti i processori sono CMP…

    @Anonymous, che dice “Ma invece di fare CPU multicore, ora che siamo a 32nm non sarebbe meglio farne una singlecore?”
    Il fatto e’ che siamo stati costretti proprio a fare il passo opposto :) Se potessimo costruire single-core sempre piu’ potenti, lo avrebbero fatto: sono piu’ semplici da programmare, e vanno piu’ veloci su ogni applicazione (parallela o no). Il problema e’ proprio che non si puo’ piu’. L’Intel ci aveva provato coll’architettura Netburst a continuare il trend e aumentare le frequenze (cioe’ il trend che e’ andato cosi’ bene per 30 anni), ma e’ stata uccisa dalla potenza dissipata.
    Se riesci ad accedere e hai tempo, guarda qui:
    http://www.stanford.edu/class/ee380/
    e guarda l’intervento registrato (o almeno le slide) di Patterson (seminario del 31 gennaio 2007). Nel caso ti sfugga il nome, sappi che e’ uno dei piu’ importanti e famosi Computer Architect al mondo (ad es. uno dei pionieri di RISC e RAID), ed e’ uno dei pezzi piu’ grossi di Computer Science a Berkeley (insomma, un pirla :) da’ una rapida spiega del perche’ siamo stati costretti a passare a multicore, e perche’ avremmo preferito non farlo :)
    Inoltre: e’ vero che oggi possiamo mettere 1-2 miliardi di transistor in un chip. La domanda e': come li usiamo? Cosa gli facciamo fare? Come trasformiamo questi MOS in potenza di calcolo? E’ molto difficile rispondere, e la risposta dell’industria (e anche della ricerca) e’ unanime: multicore (e magari il ritorno di processori vettoriali, come Larrabee).
    BTW, forse nessuno l’ha fatto notare, neanche yossarian nei suoi articoli (ma potrebbe essermi sfuggito): oggi come oggi puoi mettere un miliardo di MOS in un chip… ma non puoi accenderli tutti contemporaneamente :) sembra assurdo, ma e’ vero: non puoi far commutare l’intero chip tutto insieme, la griglia di alimentazione non reggerebbe e cmq il chip prenderebbe fuoco :) per questo le tecniche di controllo energetico sono molto raffinate: vanno dal togliere il clock a interi banchi di flip-flop che non servono in quel ciclo (risparmi potenza dinamica) a togliere l’intera alimentazione dai ring di pezzi di chip (risparmi sia la potenza dinamica che quella di leakage; in effetti, togliere l’alimentazione e’ purtroppo l’unico modo di eliminare il leakage).

  • # 36
    yossarian (Autore del post)
     scrive: 

    yossarian
    – “non so di cosa si occupi la società per cui lavori e che tipo di applicazioni usiate, però processori come gli ultrasparc della serie T1 e T2 sono indicati per applicazioni in cui il numero di thread supera quello dei core fisici (i T1 hanno 8 core e 4 thread per core e i T2 8 core e 8 thread per core) e più è elevato il rapporto tra numero di thread e numero di core, più si avvantaggia quel tipo di architettura. In caso contrario, il loro utilizzo è controproducente. Quindi l’errore è stato nella scelta di quel tipo di cpu.”

    link di chojin999
    – “All processes running on the SMT processor implicitly share the internal hardware resources of the processor. As a result, each application’s performance decreases slightly but overall system throughput increases (because internal processor resources are better utilized) [9].”

    biffuz
    – “La scelta è sbagliata nel momento in cui il numero di utenti non è tale da giustificare un aumento del numero di thread gestibili dalla CPU a scapito della velocità del singolo.”

    Marco
    “Ma allora perche’ l’avete comprato? Queste CPU sono efficienti solo quando ci sono n thread in esecuzione, e con 64 thread vantano un performance per watt ratio invidiabile.”

    fin qui si parla di ultrasparc; fino a prova contraria e purtroppo per lei, la lingua italiana o quella inglese non sono opinioni e non vale la libera interpretazione. Qui l’inglese lo conosciamo tutti e quello che è scritto li è fin troppo chiaro. O siamo tutti ignoranti, compreso chi ha scitto ciò che lei ha postato, oppure è lei che sta dicendo stupidaggini.
    Non sto a spiegarle perchè un core multithreaded, nel momento in cui elabora un unico thread, lo fa più lentamente di un core single threaded perchè non ne vale la pena.

    da qui, invece, gli attacchi personali. Come le ha fatto notare più di qualcuno e come chiunque può costatare, non sono stato io ad iniziare. Mi sono limiato a sottolineare una sua evidente carenza nell’interpretare la lingua italiana. Per dimostrarmi che mi sono sbagliato, mi mostri dove ho scritto che un chip SMT è trasparente al SO. In caso contrario eviti di mettere in bocca agli altri cose mai dette. E’ un puerile quanto inutile tentativo di far degenerare la discussione.

    chojin999
    @18,yossarian: la risposta che ha dato all’utente “biffuz” sugli Ultrasparc evidenzia che lei non ha la minima di idea del funzionamento di SMP, NUMA ed architetture multi-core nè ha la comprensione del meccanismo dei thread. Ciò che ha scritto lì in risposta è veramente una stupidaggine, glielo dico sinceramente. Non sa di cosa sta parlando. E’ inutile discutere di altri aspetti se a lei mancano le basi teoriche per comprendere la pratica di funzionamento delle architetture ed i relativi meccanismi di programmazione degli algoritmi.

    chojin999
    Questo documento spero possa essere utile come riassunto dei concetti alla base di SMP, SMT, multi-threading, scheduling che l’OS deve comunque sempre gestire (no, non funziona tutto trasparente in hardware come pensa lei):

    yossarian
    – “In quanto al resto, è evidente che lei ha seri problemi con la lingua italiana in quanto ho esplicitamente parlato di rendering 3D e di chip grafici. Quindi il “quasi trasparente all’applicazione” non è riferito a generici sistemi di tipo SMP ma a qualcosa che lei dimostra di non conoscere affatto, ossia all’architettura di un chip grafico con particolare riferimento a quelli a shader unificati. Inoltre, il “codice da elaborare”, nello specifico, non è l’OS e neppure l’API di riferimento, fino a prova contraria.
    In quanto alla confusione da lei fatta su x86, pipeline, larrabee, ecc. stendiamo un velo pietoso.”

    chojin999
    – “@yossarian: dimostra di essere veramente puerile. Non solo cita pezzi in inglese di un documento senza comprendere il significato per tentare di darsi ragione, ma oltretutto con arroganza assoluta prende ed attacca insultando anzichè riconoscere di aver torto. Torni all’asilo che a quanto sembra non vi è stato abbastanza tempo e non ha potuto sfogarsi nelle diatribe fra bambini. E’ liberissimo di restare fiero della sua ignoranza degli argomenti e di continuare a scrivere sciocchezze, ma per favore eviti di attaccare ed insultare gli altri quando le fanno notare che ha detto delle stupidaggini.
    La sua reazione conferma solo che non è in grado di discutere seriamente da persona adulta di argomenti tecnici, e vorrei farle notare che la peggior cosa che si può fare nel settore IT è quello di essere arroganti, c’è sempre qualcosa che non si sa ed è evidente che lei non conosce le basi di ciò di cui parla. Posso capire che trovarsi uno che puntualizza i suoi errori possa averla irritata, tuttavia il suo comportamento resta puerile tanto quanto assurdo, se avesse risposto con pacatezza ed un pizzico di umiltà invece di attaccare avrebbe fatto una figura sicuramente migliore e non avrei dovuto perder tempo a rispondere ai suoi patetici attacchi da bambino dell’asilo.”

    Come si può vedere, i suoi sono post contenennti solo attacchi personali che nulla aggiungono alla discussione dal punto di vista tecnico come nulla hanno aggiunto il link da lei postato che, come le ha fatto notare pleg è anche vecchio e superficiale,
    Seguono interventi di j, Cesare Di Mauro, pleg e altri utenti di cui apprezzo la preparazione mostrata in più occasioni, su questo e altri forum, mentre non abbiamo ancora avuto modo di apprezzare la sua.

    Per la cronaca, qui c’è più di qualcuno che lavora nel settore dell’IT.

  • # 37
    chojin999
     scrive: 

    @pleg: tu sei l’ennesima dimostrazione di usa gli acronimi senza sapere cosa significano. CMP sta per “single-Chip Multi-Processor”.
    L’architettura CMP era nota e studiata già negli anni ’90.. o credi forse che nell’industria ciò che oggi vedi come nuovo sul mercato sia stato progettato qualche mese fa? Mah! Se dipendesse dagli anni in cui sono stati progettati dovresti dire che è tutto vecchio e da buttare perchè il 90% di quello che usi oggi è nei laboratori delle multinazionali del settore IT da almeno un decennio, sia per l’hardware che per il software.

    Questo documento analizza i punti di vantaggio delle architetture CMP rispetto alle SMT e risale al 1997, pensa te:

    http://ogun.stanford.edu/~kunle/publications/hydra_Computer97.pdf

    […]

    On the other hand, programmers must find threadlevel
    parallelism in order to maximize CMP performance.
    The SMT also requires programmers to
    explicitly divide code into threads to get maximum performance,
    but, unlike the CMP, it can dynamically find
    more instruction-level parallelism if thread-level parallelism
    is limited. With current trends in parallelizing compilers, multithreaded operating systems, and the
    awareness of programmers about how to program parallel
    computers, however, these problems should prove
    less daunting in the future. Additionally, having all eight
    of the CPUs on a single chip allows designers to exploit
    thread-level parallelism even when threads communicate
    frequently. This has been a limiting factor on
    today’s multichip multiprocessors, preventing some
    parallel programs from attaining speedups, but the low
    communication latencies inherent in a single-chip
    microarchitecture allow speedup to occur across a wide
    range of parallelism.4

    […]

    The chip multiprocessor is a promising candidate
    for a billion-transistor architecture. On the basis
    of our simulations, a CMP offers superior performance
    using relatively simple hardware. On code
    that can be parallelized into multiple threads, the
    many small, high-performance CMP cores working
    together will perform comparably to—or better
    than—more complicated wide-issue superscalars or
    SMTs on a cycle-by-cycle basis. They are also much
    easier to design and optimize. Additionally, several
    small, high-performance cores with tightly integrated
    data caches should allow higher clock rates and/or
    shorter pipelines in the CMP. SMTs can almost always
    use execution resources more efficiently than CMPs,
    but more execution units can be included in a CMP
    of similar area, since less die area need be devoted to
    the wide-issue logic. As a result, they perform and utilize
    area comparably on multithreaded code.
    The primary disadvantage of the CMP is that it is
    slower than the more complex architectures when presented
    with code that cannot be multithreaded, because
    only one processor can be targeted to the task.
    However, a single 2-issue processor on the CMP is usually
    only moderately slower than superscalar or SMT
    architectures, since applications with little thread-level
    parallelism often also lack instruction-level parallelism
    that can be exploited by superscalar processors. Also,
    the remaining processors are free to increase system
    throughput by running independent processes.
    We have shown that CMPs are already a strong billion-
    transistor architecture, even with today’s applications
    and compilers. As application software
    increases the use of thread- and process-level parallelism,
    CMPs will become a better solution in the
    future. Emerging operating environments and applications,
    such as multimedia, inherently will possess
    larger amounts of parallelism, and future research into
    parallel compilers will extend multiprocessors’ reach
    into currently hard-to-parallelize applications.

    ——–

  • # 38
    chojin999
     scrive: 

    @pleg: hai scritto una bestialità unica sopra:
    “BTW, forse nessuno l’ha fatto notare, neanche yossarian nei suoi articoli (ma potrebbe essermi sfuggito): oggi come oggi puoi mettere un miliardo di MOS in un chip… ma non puoi accenderli tutti contemporaneamente :) sembra assurdo, ma e’ vero: non puoi far commutare l’intero chip tutto insieme, la griglia di alimentazione non reggerebbe e cmq il chip prenderebbe fuoco :) per questo le tecniche di controllo energetico sono molto raffinate: vanno dal togliere il clock a interi banchi di flip-flop che non servono in quel ciclo (risparmi potenza dinamica) a togliere l’intera alimentazione dai ring di pezzi di chip (risparmi sia la potenza dinamica che quella di leakage; in effetti, togliere l’alimentazione e’ purtroppo l’unico modo di eliminare il leakage).”

    Ma ci credi davvero ?? Che cosa diavolo c’entrano i sistemi di risparmio energetico che spengono le varie sotto-unità delle CPU per risparmiare corrente a seconda del carico di lavoro (occupazione in percentuale dei vari core della CPU) con il tenerla accesa tutta quanta? Ma che dici? Come puoi anche solo pensare che non si possa usare tutta una CPU ?
    Non la puoi usare se si surriscalda e non è ben raffreddata, sempre per i meccanismi di sicurezza e risparmio energetico (collegati fra loro) se la temperatura salisse per una ventola difettosa o altri problemi le CPU moderne inizierebbero a rallentare e poi se necessario spegnersi per non bruciarsi.
    Ma se funziona tutto certo che puoi usare l’intera CPU e tutte le sue unità alla massima potenza! Altrimenti nessuna CPU secondo il tuo ragionamento potrebbe essere utilizzata alla massima potenza di calcolo. Non lo capisci che hai detto una bestialità?
    Anche le CPU multi-core attuali.. una Quad-Core puoi usarla eccome al 100% di carico continuato su tutti i 4 core facendo uso di tutte le sottounità vettoriali SSE e le FPU.. e le cache L1,L2,L3 verrano utilizzate tutte quante. Certo che la CPU è attiva in tutte le sue sottounità. Non salta nulla! Altrimenti esisterebbero solo CPU difettose.

  • # 39
    yossarian (Autore del post)
     scrive: 

    @ chojin999

    mi linki dove pleg avrebbe dimostrato di non conoscere l’acronimo CMP? E mi linki dove avrebbe scritto che negli anni ’90 non erano allo studio architetture CMP?

    Se ci sei, allora ho ragione a dire che hai problemi con la lingua italiana, se ci fai lascia perdere: ci sono molti modi per partecipare ad una discussione e attaccare gli altri non rappresenta il miglior biglietto da visita.

  • # 40
    pleg
     scrive: 

    yossarian, ma lascialo stare, non vedi che delira, che non riesce nemmeno a leggere cosa scriviamo?

    Cmq, mi sono fatto una gran risata quando ho visto il link che ha postato, il progetto Hydra di Kunle Olukotun… perche’ Kunle e’ stato il mio professore di Parallel Computer Architecture & Programming (corso CS315A) due trimestri fa, qui a Stanford :) come puoi immaginare conosco abbastanza bene quell’argomento :) (Kunle stesso mi invito’ a lavorare nel suo gruppo di ricerca, ma ho preferito tornare nell’industria).

    Naturalmente, non posso provarlo… ma posso sempre far comparire un messaggio sulla mia home page:
    http://www.stanford.edu/~signorda/
    :)
    e linkarti al mio lavoro che ho fatto per il corso (uso di CUDA per un algoritmo di machine learning: abbiamo scoperto che non si puo’ fare!) :
    https://ccnet.stanford.edu/cgi-bin/course.cgi?cc=cs315a&action=main_page&link_id=link1&sidebarlink=1

    (progetto ERT, indovina chi e’ l’italiano :)

  • # 41
    Cesare Di Mauro
     scrive: 

    A meno che, oltre all’inglese, anche l’italiano sia diventata una lingua opinabile, mi sembra che pleg abbia parlato di far commutare tutti i TRANSISTOR nello stesso momento, e MAI ha parlato di:
    – usare tutta la CPU (addirittura “al massimo della potenza di calcolo”);
    – usare tutte le sue unità di calcolo (anche qui “al massimo della potenza”);
    – usarla “al 100% di carico”.

    Fermo restando che quando si parla fra professionisti almeno certi concetti è bene definirli in maniera precisa e rigorosa (e mancando quelli virgolettati mi aspetto, pertanto, una futura integrazione), sarebbe interessante avere una dimostrazione, anche non strettamente formale, di come sia possibile ottenere quanto detto in merito.

    Al limite mi accontenterei anche di un esempietto da due soldi, purché copra esattamente i casi citati.

    Come dice un antico proverbio, “chi di bestialità ferisce, di bestialità perisce”.

    @Marco: la tua è una curiosità che non verrà mai appagata. E di questo ne è cosciente chi ha un briciolo di esperienza in materia.

  • # 42
    pleg
     scrive: 

    @Cesare Di Mauro

    Esatto, ovviamente parlavo di tutti i transistor (pensavo fosse chiaro, ma forse non ho esplicitamente scritto la parola nel mio mex precedente), e non di tutte le unita’ funzionali. Se facessi commutare tutto il miliardo di MOS nello stesso momento, si fonderebbe la PGGrid (o mi elettromigra tutto :) e prenderebbe fuoco il chip!

    Un paio di considerazioni extra:

    – e’ interessante vedere il “boost mode” (o come si chiama) del Nehalem al contrario: invece di dire “quando lavora un solo core gli alziamo la frequenza”, dire “quando lavorano tutti e 4 i core, dobbiamo abbassare la frequenza per rientrare nel power budget” :) abbassare la frequenza e abbassare la tensione di alimentazione (come diceva yossarian nell’articolo) ti permettono di avere tutti e i 4 core funzionanti senza bruciare tutto

    – quasi due anni fa parlavo con uno di synopsys che aveva lavorato all’automazione del design delle reti di distribuzione del clock; diceva una cosa molto interessante: che erano riusciti ad automatizzare (per design medi) una tecnica di “clock spreading”, per cui inserivano dello skew… apposta! Invece di cloccare tutti i flop insieme (e minimizzare lo skew), “disperdevano” i fronti di clock (su un centinaio di ps, mi pare) ovunque possibile (ovunque riuscivano cmq a chiudere i timing). In questo modo riduci il picco di corrente assorbita nell’istante della commutazione, e quindi: 1. riduci il rumore di/dt sulla linea; 2. riduci la IRdrop sull’alimentazione; 3. riduci l’EMI a livello di chip.

  • # 43
    Cesare Di Mauro
     scrive: 

    Ma no, già dal contesto era lapalissiano che ti riferissi ai transistor. Non si può pensare altrimenti, perché significherebbe aver cannato completamente il significato delle tue parole.

    A parte questo, l’avevi pure scritto:

    “oggi possiamo mettere 1-2 miliardi di transistor in un chip”

    P.S. Mi sono ribaltato quando ho visto che lavori alla Stanford. Ho riso come un dannato. :D

    Certe cose sono IM-PA-GA-BI-LI. :D :D :D

    E complimenti per il tuo lavoro. :)

  • # 44
    chojin999
     scrive: 

    @pleg: se fossi tu quello che dici di essere alla Stanford non scriveresti in anonimato con nickname. E poi guarda caso perchè ho linkato dei documenti della Stanford University te ne esci affermando di essere un italiano che lavora lì? Ma quanti anni hai, 10 o 12 ? Ne dimostri 5. Se mettessero a lavorare gente che non sa niente di architetture come te andrebbero falliti. Le università USA non sono come quelle italiane, chi non produce viene licenziato.

  • # 45
    chojin999
     scrive: 

    @pleg: comunque dovresti sapere del fuso orario che c’è fra USA ed Italia… in pratica tu invece di lavorare se stessi scrivendo davvero dalla Stanford University dove affermi di lavorare entreresti la mattina e te ne staresti a scrivere sui blog italiani… e non ti hanno ancora licenziato? Ehh!

  • # 46
    chojin999
     scrive: 

    @pleg: visto che dovresti parlare l’inglese come l’italiano è singolare che non ricordi il semplice e banale “turbo mode” dei Nehalem.. (o stavi pensando alla serie tv Knight Rider, Supercar in Italia, con K.I.T.T. che ha il “turbo boost”? Mah!)

    http://www.krunker.com/category/computers/cpus/intel-nehalem/

    The majority of the details were focused of course on Nehalem which Intel will begin releasing during the fourth quarter of this year. The company released additional information regarding Nehalem including:

    * Nehalem comes with a “Turbo mode” which is a power management feature that allows unused idle processing cores to be powered down for power conservation. More on Turbo mode below (and why it’s called Turbo mode). This will be available in both Nehalem-based notebooks/laptops and servers.
    * Turbo Mode is based possible thanks to an integrated microcontroller which handles the core power management

  • # 47
    Cesare Di Mauro
     scrive: 

    Non ricordare in maniera precisa un termine non è un crimine. La cosa più importante è ricordarne bene il significato, come ha dimostrato pleg.

    Per il resto, continua pure

  • # 48
    chojin999
     scrive: 

    @Cesare Di Mauro: sì, come no.. per uno come “pleg” che se ne esce dicendo di essere un esperto di architetture di CPU, un progettista ricercatore afferma e non fa che citare acronimi e termini, e per ciò che lui stesso afferma l’inglese dovrebbe essere come la prima lingua per lui (altrimenti come fa uno a lavorare fra persone di madre lingua inglese?) direi che infatti non è grave, è semplicemente ridicolo. Un professionista non si mette a citare i termini a caso. Il significato dice poco, può averlo letto su uno dei tanti siti su internet, avrà letto una descrizione in cui si parla (e molte sono così) di “thread boost” o “clock boost” e così senza guardare che il termine commerciale dato alla tecnologia da Intel è invece “Turbo Mode” lui ha semplicemente preso e scritto là pensando che tanto non avrebbe cambiato nulla il non sapere il nome esatto… peccato che faccia differenza eccome la cosa quando uno se ne esce affermando di essere un professionista del settore in una delle più prestigiose università del mondo.

  • # 49
    chojin999
     scrive: 

    Ah, comunque riguardo il Turbo Mode dei Core i7 Nehalem .. è una tecnologia di risparmio energetico. Il fatto che alza la frequenza di clock quando si usano tipo 1 o 2 core invece di tutti e 4 non significa che i 4 core non possano andare più veloci tutti assieme. Sì, le architetture multi-core impongono un clock più basso quanti più clock ci sono MA molto è per scelta commerciale.
    Infatti prendiamo per esempio un Core i7 920 Nehalem.. ha il clock ufficiale su tutti i 4 core a 2.66GHz. Mettiamo che con il Turbo Mode vada a 3GHz su soli 2 core o 1 core che vengono utilizzati e gli altri due si spengono per risparmiare corrente se non utilizzati.
    Significa forse che se tutti e 4 i core della CPU andassero a 3GHz questa esploderebbe secondo il sedicente ricercatore professionista esperto di architetture “pleg” ?
    Bhè, allora come si spiega che la Core i7 920 Nehalem sia stata portata facilmente in overclock da tempo a ben 4GHz con tutti e 4 i clock perfettamente utilizzabili al 100% di occupazione?
    Uno dei tanti esempi:

    —–
    http://www.overclockers.com/index.php?option=com_content&view=article&id=4281:corei7oc&catid=57:processors&Itemid=4263

    Also true to form, overclocking the 920 is ridiculously easy – crank up the FSB, watch temps and you get darn close to 4 GHz for something approaching a 50% overclock. If you don’t want to upgrade the stock Intel heatsink, you may have to settle for something around 3.5 GHz, a “measly” 30% overclock. All this with maybe ten minutes effort. Compared to what some of us fossils used to do, such as polishing a Celeron IHS or cooling CPUs front and back, the sweat value of overclocking is getting close to infinity.

    bit-tech.net

    “Pushing the Core i7 920 up to 4GHz was fantastically easy to get stable. However, when we tried to take things beyond 4GHz, it was like we had hit a stability brick wall….In a nutshell, the Core i7 920 is an overclocking monster and it delivers industry leading video encoding, image compressing, thread munching behemoth and a great value CPU. However, it sits in an expensive new platform that sniffles at games [my emphasis], still. Most of us will want to wait this launch out and see what happens as DDR3 kits drop in price and new X58 boards are launched.”
    ——–

    E quindi il limite di clock per i 4 core sulla i7 920 è di ben 4GHz.. molto oltre quanto spinge il Turbo Mode un singolo core o due core quando gli altri non sono utilizzati.
    Come sarebbe mai possibile? Non dovrebbero bruciarsi? Non dovrebbe esplodere la CPU ? Eh, ma invece funziona eccome e va ben oltre le specifiche dichiarate e tutti i 4 core sono attivi e funzionanti. Ehh!

  • # 50
    Cesare Di Mauro
     scrive: 

    Non ricordare un termine come quello quando si sta scrivendo un commento di getto è perfettamente naturale.

    Ad esempio, pur dedicandomi allo studio delle architetture degli elaboratori, ogni volta che devo riportare l’esatto nome della GPU della PS2, devo fare una ricerchina su google o consultare wikipedia, perché di ricordarlo subito non se ne parla proprio, nonostante le innumerevoli volte che l’abbia letto e citato.

    Per quanto riguarda il Turbo Mode di Nehalem, non mi sembra che pleg abbia voluto far passare ciò che hai scritto.

    Infine, visto che parliamo di professionismo, di termini, e di acronimi che devono essere esatti, mi aspetto che tu faccia altrettanto con le cose che ho riportato in un mio precedente messaggio e che… ti appartengono.

    Definizioni rigorose e, meglio ancora, le dimostrazioni richieste, sono particolarmente gradite.

  • # 51
    yossarian (Autore del post)
     scrive: 

    @ chojin999

    hai rivelato a tutti il troll che sei.

    1) Per quale motivo pleg non potrebbe postare con un nick?

    Conosci questo signore?

    http://www.beyond3d.com/content/interviews/39/

    Immagino di no. Per la cronaca è uno dei principali progettisti in ATi (sai di cosa si tratta?).

    Questo è il nick che utilizza aui forum

    http://74.200.65.90/member.php?u=853

    Come suppongo non conosci, ad esempio, Francesco Carucci, al secolo e sui forum “fek” che lavora in Crytek.

    Dove sta scritto che non ci si possa iscrivere con dei nick su un forum? Cos’è, una tua nuova regola? E siamo tutti tenuti a rispettarla?

    2) come ti ha già spiegato Cesare, il non aver definito in maniera corretta una funzionalità il cui nome commerciale, e sottolineo commerciale, è turbo mode, termine che tecnicamente non ha alcuna valenza (poteva chiamarsi anche pippo), non è affatto grave. Lo è molto di più il non sapere di cosa si sta parlando e, nonostante ciò, insultare altri utennti. Se non riesci a distinguere tra un nome di fantasia ed un termine tecnico, il problema è solo tuo.
    Ora, per cortesia, se vuoi continuare ad usare questi toni e a postare trollate offensive nei confronti di chi scrive e di chi legge, ti invito a trasferirti su altri blog, dove magari si parla di veline, amici, de filippi o belen rodriguez.
    In caso contrario, ogni tuo intervento ulteriore sarà sottoposto a moderazione con esiti facilmente immaginabili.

  • # 52
    Cesare Di Mauro
     scrive: 

    Tra l’altro se pleg avesse voluto conservare l’anonimato non avrebbe nemmeno riportato quei due link, coi quali si è “sputtanato”, come si suol dire, visto che in un paio di secondi si arriva alla sua identità.

    Vero, “Signor Elli”? :D

  • # 53
    pleg
     scrive: 

    @Cesare Di Mauro

    Grazie :)
    Cmq non sono ricercatore, sto solo facendo un master in EE (computer hardware & architecture) per poi cercare di entrare in qualche azienda qua intorno.
    Di solito non mi va scrivere cose cosi’ in un forum pubblico, perche’ c’e’ chi parte con “e io invece lavoro alla Intel”, “io ho costruito la Morte Nera” ecc.
    Pero’ quando mi ha tirato in ballo Kunle, non ho resistito ( “certe cose non hanno prezzo” :) che e’ anche un’ottima persona BTW, oltre che uno dei pionieri dei CMP e il tizio che sta dietro ai Sun Niagara (che sono derivati dai suoi Afara chip, a loro volta derivati dal progetto Hydra).

    Nota di colore: per progettare l’Afara (poco diverso dal Niagara), avevano un team di… 6 progettisti! Piu’ poche decine di altri per il physical design, verification ecc. Confrontalo coi team di centinaia di persone che mette in campo l’Intel (o AMD)… Il fatto e’ che la pipeline del Niagara (il primo) e’ poco piu’ della classica in-order, 5 stage pipeline! Hanno giusto uno stage in piu’ per la selezione del thread da mandare in pipe a quel ciclo di clock (oltre alla logica di selezione, a moltiplicare per 4 i registri, e ad una interessante gerarchia di cache L1-L2).

    Su una sola cosa chojin999 ha ragione: che dovrei lavorare :) ma in questi giorno sono in fase di cazzeggio assoluto (gia’, succede anche qui).

  • # 54
    chojin999
     scrive: 

    Ma quanto siete ridicoli. Dire con un link “sono questo tizio” non significa certo esserlo. Poteva anche dire di essere il Presidente Obama… ehh! Ma per favore!
    E che “pleg” avrebbe detto che poteva scrivere qui perchè dovrebbe lavorare ma non lavora (e non lo licenziano? Mah! Negli USA a Stanford lo lasciano perder tempo tutto il giorno senza licenziarlo?) è la classica scusa scontata tanto quanto ridicola che era prevedibile avrebbe detto per giustificare alla meno peggio la sua sparata di affermare di essere chi non è.
    Quello che posso pensare è che il tizio a cui fa riferimento che lavora a Stanford magari lo conosca davvero, possa essere un suo parente o un suo amico.. ma che sia lui non ci credo proprio. Ma può anche essere che abbia avuto l’alzata d’ingegno di spararla grossa e tirare in ballo il nome di uno che proprio non sa chi è solo perchè ha visto i documenti a cui ho fatto riferimento che sono scritti da ricercatori di Stanford e così si è inventato la storiella che lavora lì, che ha studiato lì.. e via dicendo.
    Se avessi messo dei link di un’università a Tokyo avrebbe detto che viveva in Giappone ed aveva studiato lì e lavorava in quell’università.. ehh!
    Veramente ridicolo. Inventarsi delle storie per voler aver ragione a tutti i costi ed insultarmi in coro.. siete peggio dei bambini dell’asilo. Se non sapete le cose dovete prendervela con voi stessi non con chi fa notare i vostri errori. Insultando gli altri ed inventandosi storie su storie per darsi ragione va oltre la puerilità, è da psicanalisi.

  • # 55
    chojin999
     scrive: 

    @pleg: guarda che dovresti leggere meglio le cose se vuoi inventarti le storie. La tecnologia Afara la Sun la acquistò nel 2002, non la progettò. Infatti:

    —-
    http://www.ambarella.com/about/leadership/wang.htm

    Fermi Wang co-founded Ambarella Inc. in 2004 to drive innovation in video compression for hybrid digital cameras and define a new class of consumer products.

    Prior to founding Ambarella, Wang was CEO and co-founder of Afara Websystems, a startup that pioneered throughput computing for servers. Afara was acquired by Sun Microsystems in July 2002. The multi-core, multi-thread CPU design developed at Afara is the critical technology in Sun’s current roadmap for its UltraSPARC processors.

    Before founding Afara, Wang held several senior management positions at C-Cube Microsystems. As vice president and general manager of the Home Media division, he had P&L responsibility for silicon solutions for the DVD, digital video recorder (DVR) and digital video distribution and production markets. As vice president and general manager of the company’s codec division, he launched the company’s MPEG codec business and served in both engineering and business management roles. During this time, Wang and his team were responsible for growing the business by 200 percent in two years and developing the world’s first MPEG codec chip.

    Wang owns several digital video-related patents; one of them is accepted by MPEGLA as one of the key MPEG-2 and MPEG-4/AVC patents. Fermi Wang received his bachelor’s degree in electrical engineering from National Taiwan University and earned his master’s and doctorate degrees in electrical engineering from Columbia University.

    ———

    Ora dirai che hai lavorato anche all’università di Taiwan ed in quella di Columbia e sei esperto anche di codifica video?

  • # 56
    pleg
     scrive: 

    Beh, chojin999, adesso sei veramente patetico.

    1. Immagino che dirai che di quel “ricercatore che non sono io” ho anche craccato la pagina web per lasciarti un messaggio
    http://www.stanford.edu/~signorda/
    ?
    Perche’ non gli scrivi sull’email di Stanford, e vedi chi risponde? sorpresa…

    2. Io dico “i Sun Niagara sono derivati dagli Afara”. Tu rispondi “Ti inventi le cose: La tecnologia Afara la Sun la acquistò nel 2002, non la progettò.”
    Ehmm… si? quale parte di “derivati” significa “progettati da zero”? Neanche l’italiano di base sappiamo, eh?

    Bah.

  • # 57
    chojin999
     scrive: 

    @pleg: non dimostra che tu sia chi dici di essere l’avere accesso ad un account in un utente in un’università. Puoi avere accesso perchè è un tuo amico o parente o conosci qualcuno che lavora lì che ti ha dato l’abilitazione. Se fosse vero che sei assunto lì e puoi permetterti di non lavorare non stai certo lì per bravura ma per raccomandazione perchè i non raccomandati li licenziano in tronco se non lavorano.

  • # 58
    Cesare Di Mauro
     scrive: 

    E’ raro veder rosicare così tanto una persona.

    A parte i soliti insulti gratuiti che fanno tanto “professional”, immagino che pleg avrebbe dovuto falsificare anche l’IP (unico) usato per scrivere tutti i commenti in quest’articolo, e questo fin dal primo, cioé in tempi “non sospetti” (leggi: prima dei tuoi attacchi).

    Beh, diciamo che NON è un utente di Roma che cazzeggia con l’ADSL di Telecom, ma è LEGGERMENTE fuori mano. E dovresti immaginare dove…

    Ma sicuramente avrà falsificato anche l’IP, oltre alla paginetta di cui sopra, perché il suo era un piano machiavellico: fin dall’inizio mirava già a farsi insultare da te per poi combinarti quello scherzetto.

    Anzi, è talmente diabolico che ha usato lo stesso IP in altre occasioni. Proprio perché è un genio criminale dotato di poteri paranormali e aveva previsto tutto…

  • # 59
    Marco
     scrive: 

    @chojin999
    Che pleg lavori a Stanford, che sia un utente di Roma che cazzeggia, o il benzinaio che ho sotto casa (btw una delle persone piu’ eclettiche ed erudite che conosca) poco importa: ha dimostrato la sua ragione con argomentazioni fondate.
    Tu invece continui a blaterare e a glissare sulle precise domande che ti sono state fatte.

  • # 60
    yossarian (Autore del post)
     scrive: 

    @ pleg

    il power gating del nehalem ha una caratteristica peculiare: non fa uso di due soli stati che potremmo definire on e off per i core, ma di tre; oltre ai primi due, c’è una sorta di modalità “standby”. Quando uno o più core entrano in modalità “standby, non vengono spenti ma la potenza ad essi destinata viene dirottata sui core rimasti attivi. In questo modo è possibile aumentare la frequenza di questi ultimi mantenendo contenuti i consumi e la potenza comlessiva da dissipare. Inoltre, i core in standby sono più reattivi nell’effettuare lo switch (uno dei problemi dei meccanismi classici di clock o power gating è proprio che i tempi richiesti per le operazioni di switch possono portare ad un abbattimento delle prestazioni complessive che può raggiungere anche un 10-12%).
    Per gestire in maniera ottimale le tre fasi (on, off, standby) in modo da conciliare al meglio prestazioni e consumi, è stato utilizzato un circuito piuttosto complesso, controllato da una sorta di processore all’interno della cpu che, a detta di Intel, ha più transistor di un 386.

  • # 61
    Anonymous
     scrive: 

    Uno dei motivi per cui ormai non leggo più i commenti su qualunque sito/forum è che si finisce sempre alla solita maniera. Non capisco perchè ogni volta bisogna attaccarsi l’uno con l’altro.
    Avevo delle domande da fare ma mi è passata la voglia leggendo queste cose.

  • # 62
    Alessio Di Domizio
     scrive: 

    @ anonymous
    Mi dispiace che saltino fuori considerazioni come le tue, è davvero l’ultima cosa che vorrei per AD e lavoro giorno e notte per evitarla. Se fai tuttavia uno sforzo di analisi in più ti rendi conto che il tutto è partito da alcune provocazioni gratuite e che di gente competente e disponibile al dialogo ce n’è.

  • # 63
    chojin999
     scrive: 

    @Cesare Di Mauro: a parte che può usare un qualsiasi proxy per avere un IP non italiano… ma poi sarei io quello che deve rosicare? Di cosa? Se ciò che dice “pleg” fosse anche la verità avrebbe solo dimostrato di essere un raccomandato infilato a Stanford che sta lì “a cazzeggiare”, sue parole, invece di lavorare. E poi poco importa che metta su una paginetta web nell’università affermando di aver lavorato a chissà che progetti. Può aver fatto magari le fotocopie ai professori nei progetti e basterebbe per dire che è lavorato alla progettazione…
    @Marco: le affermazioni di “pleg” dimostrano solo che non sa cosa sta dicendo. Uscirsene con CPU che esplodono se usate al 100% è ridicolo, secondo lui i Nehalem non si dovrebbero poter overclockare perchè altrimenti andrebbero a fuoco.. eppure vanno a 4GHz i Core i7 920 2.66GHz senza bruciarsi e con tutti e 4 i core attivi al 100% di utilizzo.
    Un presunto progettista di CPU che dice simili boiate, perchè sono boiate, non è credibile. Ok, sarà un raccomandato infilato a Stanford.. ed allora? Le sue affermazioni restano quelle di uno che non sa di cosa parla e sono delle bestialità che un progettista serio non direbbe mai. Poi in tutti i posti di lavoro c’è “chi cazzeggia” perchè gli viene permesso di farlo. Che tristezza, un tempo a Stanford raccomandati così non venivano permessi. Un altro mito che cade.

  • # 64
    Marco
     scrive: 

    Ancora una volta: “Uscirsene con CPU che esplodono se usate al 100%”. Non hai capito una mazza. Si parlava di far commutare tutti i transistor contemporaneamente, come ti e’ gia’ stato detto, ma evidentemente non cogli la differenza.

  • # 65
    Medicina
     scrive: 

    A certi commenti non si dovrebbe rispondere…

  • # 66
    Biffuz
     scrive: 

    @Marco

    Quando si replica ad un altro commento, sarebbe educato considerare TUTTO il messaggio, non solo estrapolare delle frasi.

    [i]@biffuz
    “la maggior parte del tempo quindi la CPU lo passa ad aspettare la risposta dal DB”

    E qui il problema non è certamente il T2.[/i]

    Mi sembrava fosse abbastanza chiaro, dato il resto della spiegazione. Anzi, ho detto esplicitamente che la scelta era sbagliata.
    E comunque la frase si commentava da sola.

    [i]“La scelta è sbagliata nel momento in cui il numero di utenti non è tale da giustificare un aumento del numero di thread gestibili dalla CPU a scapito della velocità del singolo.”

    Ma allora perche’ l’avete comprato? Queste CPU sono efficienti solo quando ci sono n thread in esecuzione, e con 64 thread vantano un performance per watt ratio invidiabile.[/i]

    Infatti avevo scritto anche che la scelta era stata fatta da una persona ritenuta competente (ora aggiungo che altre persone quando l’hanno saputo si sono strappate i capelli).

    [i]“è ovvio che la Sun si sia preoccupata”
    LOL
    Preoccupata di cosa? Che i loro clienti non sappiano scegliere la macchina adatta al tipo di workload?[/i]

    Cosa c’è da ridere? Non stiamo parlando di un pizzaiolo che compra il server per gestire le ordinazioni. Stiamo parlando di una grande azienda, simile in tutto e per tutto a svariate altre grandi aziende che rappresentano una fetta importante della clientela Sun e che non trovano adatto ai propri bisogni uno dei prodotti di punta di quest’ultima, per il cui sviluppo sono state spese cifre molto importanti.
    Lo stop allo sviluppo della nuova generazione mi sembra un segnale importante.

  • # 67
    Alessio Di Domizio
     scrive: 

    Ogni successivo commento contenente offese personali sarà moderato. Reiterati tentativi di turbare la tranquillità della discussione risulteranno in un ban.

    @ chojin
    Se non riesci a mantenere la discussione sul solo merito tecnico esimiti dal commentare.

  • # 68
    Marco
     scrive: 

    “Cosa c’è da ridere? Non stiamo parlando di un pizzaiolo che compra il server per gestire le ordinazioni.”

    Scusa, ma allora a maggior ragione. Ad un pizzaiolo ci puo’ anche stare che gli venga propinata una macchina non conforme alle sue esigenze.

    “che non trovano adatto ai propri bisogni uno dei prodotti di punta di quest’ultima”

    Ma che discorsi sono? Perche’ un Blue Gene sarebbe adatto allora? O un Altix? O un Integrity Non Stop?
    Hai detto che tornerete a Xeon? Beh, Sun ne ha in catalogo una ventina di modelli, piu’ altrettanti con Opteron, basta saperli scegliere. Se poi un consulente vi dice di prendere un Constellation per farci girare jboss che fate? Date la colpa a Sun? XD

  • # 69
    Simon71
     scrive: 

    E intanto però le frequenze salgono, poco, ma salgono…
    Non c’è niente da fare, io ho un vecchio P4 a 3.2ghz e un C2D a 2Ghz…Nei task singoli il P4 è più veloce, malgrado la “ridicola” Cache L2, e l’architettura nerburst…

  • # 70
    Cesare Di Mauro
     scrive: 

    Come ha ricordato nuovamente Marco, si parlava di TRANSISTOR.

    Poi sarebbe interessante avere una definizione oggettiva e rigorosa di “core al 100% di utilizzo”. E tutte le altre domande che ho posto e a cui mancano ovviamente le risposte.

  • # 71
    chojin999
     scrive: 

    @Alessio Di Domizio: Vi siete qualificati con questa Sua uscita. Qui l’unico ad aver ricevuto insulti sono stato io. Minacciare di ritorsioni chi Vi riprende su degli errori è veramente squallido. A quanto sembra nessuno di Voi è in grado di discutere in maniera civile ed adulta. Non potete pensare di obbligare gli altri a dire ciò che Vi piace e Vi fa comodo. Il Vostro comportamento è veramente professionale, si vede. Eh!

  • # 72
    Cesare Di Mauro
     scrive: 

    Veramente stiamo ancora aspettando di capire quali sarebbero questi presunti errori.

    Qui finora c’è chi scambia transistor per core, riporta termini tecnici privi della benché minima definizione formale, parla di scheduler dei s.o. ignorando che non tutti i kernel implementano la gestione di thread e processi allo stesso modo, parla alacramente di parallelizzazione a tutto spiano “dimenticando” i problemi di dipendenza dei dati.

    E ovviamente a precise domande in merito fa “puntualmente” mancare le risposte.

    I professionisti hanno sempre risposto. Quelli cresciuti a colpi di wikipedia e google no. Per me ce n’è già abbastanza per capire come stanno le cose.

  • # 73
    Alessio Di Domizio
     scrive: 

    @ chojin

    A parte l’articolo che mischia concetti e termini in maniera confusionaria, tanto è che le architetture pipeline e superscalar non c’entrano nulla con multi-core ed SMP… (per la cronaca la prossima architettura Tera-scale di Intel per CPU multi-core così come anche Larrabee, i due progetti sono stati sviluppati in parallelo e collegati fra loro per vari aspetti, prevedono la possibilità di avere core anche non x86 specializzati, come ad esempio dei core dedicati all’esecuzione accelerata di codice di macchine virtuali Java e .NET, core dedicati all’accelerazione floating point e così via..)
    Ma poi i commenti all’articolo che si leggono… ma avete qualche idea di cosa state parlando? A me sembra proprio di no.

    Questo è l’incipit del tuo primo intervento. Il primo a usare toni offensivi sei stato tu, ed è per questo che mi rivolgo a te. Se non fossi partito con quest’invettiva, e più pacatamente avessi posto le questioni tecniche sulle quali mi pare che ancora tu abbia da fare totale chiarezza, nessuno ti avrebbe risposto male.

    Ad ogni modo quanto detto nel mio precedente commento vale tanto per te come per chiunque altro.

    Infine se trovi questo sito squallido, cercatene pure un altro.

  • # 74
    pleg
     scrive: 

    @yossarian (post #60)

    Non sono un esperto di low power (mai progettato niente, solo letto qualcosa), ma provo ad aggiungere qualche cosa.
    Ci sono molti modi e granularita’ per diminuire il consumo energetico, e in generale (come ovvio) piu’ diminuisci il consumo, piu’ tempo ci vuole a far ripartire il sistema.

    Il livello piu’ rapido, a granularita’ piu’ fine, e che fa risparmiare di meno, e’ il clock gating a livello di banchi di flop o unita’ funzionali: togliendo il clock elimini la potenza spesa per commutare le linee di clock e le porte CK dei flop; questo puoi farlo praticamente ciclo di clock per ciclo di clock (estremamente fine, quindi). Non togli l’alimentazione, quindi lo stato e’ conservato, e puoi far ripartire il sistema al ciclo di clock dopo (istantaneo). Con questa tecnica ad es. puoi staccare il clock ad una unita’ funzionale quando non la usi (questo te lo puo’ dire il front-end del processore, dopo l’instruction decode).

    Piu’ aggressivo, puoi togliere il clock a blocchi piu’ grandi (un intero local domain, o addirittura core).

    Ancora piu’ aggressivo, puoi spegnere il clock del tutto, spegnendo i PLL. Qui ti ci vuole piu’ tempo a ripartire, perche’ devi riaccendere il PLL e riportarlo alla frequenza giusta (so molto poco di PLL, so che hanno fatto un grosso lavoro per avere PLL con un lock-time molto breve, ma non so dare numeri). Pero’ risparmi _tutta_ la potenza di commutazione del clock (che puo’ essere molto alta: nell’Itanium Montecito era il 25% dell’intera potenza del chip, solo per distribuire il clock! Puo’ essere anche maggiori, in certi casi).
    In questo caso, cmq, ancora puoi mantenere lo stato dei flop.

    Ancora piu’ aggressivo: power gating. L’intero ring di alimentazione e’ collegato all’alimentazione principale tramite dei MOS _LARGHI_ (enormi! occupano un’area non trascurabile! il fatto e’ che la loro resistenza di on deve essere minuscola, e quindi devi farli larghissimi). Chiudi i MOS, togli l’alimentazione (puoi farlo a livello di core, o meno). Questo e’ l’unico modo per eliminare la corrente (e quindi dissipazione) di leakage, che e’ dovuta principalmente alla corrente di polarizzazione inversa delle giunzioni PN (es: N well con substrato P).
    Il consumo va a zero, ma perdi lo stato dei flop (o della SRAM, per la cache). Questo comporta un tempo di riattivazione molto piu’ lungo, composto principalmente da due componenti:
    * il tempo per ridare corrente al chip (accendere i MOS di gate, far ristabilizzare la tensione di alimentazione sull’intero ring); questo e’ un tempo “hardware”, e non e’ quello dominante
    * il tempo per ricaricare lo stato del processore: questo lo fa (credo) il sistema operativo, ed e’ il tempo dominante: devi ricaricare tutti i registri necessari dallo stato salvato in memoria
    [in piu’, potrebbe volerci del tempo per ricaricare le cache e la TLB, che ripartono da uno stato “cold”, dipende dall’applicazione]

    Ci saranno sicuramente tanti step intermedi, che dipendono dalla microarchitettura.

    BTW: non mi sorprende affatto che il gestore energetico sia piu’ grande di un 386! Pensa alla complicazione di gestire tutti questi stati in modo efficiente. Inoltre, puo’ essere molto difficile costruirlo in modo affidabile: pensa a fare il clock gating ciclo per ciclo, NON puoi permetterti ASSOLUTAMENTE di introdurre glitch sulle linee di clock, o perdi tutta la baracca (i flop si caricano con valori a caso, e sei finito). La timing analysis per garantire uan logica glitch-free dev’essere un incubo (e se sbagli, son dolori, altro che il float divide bug del pentium!).

  • # 75
    pleg
     scrive: 

    Correzione: se un’unita’ funzionale e’ inutilizzata lo sai all’instruction dispatch, non decode (per un superscalare out-of-order): il decode manda solo le istruzioni all’instruction window / dispatch buffer, non sa chi va in esecuzione o quando.

  • # 76
    yossarian (Autore del post)
     scrive: 

    @ pleg

    ti ringrazio per avermi fornito più di un valido spunto per un prossimo articolo.

    Ciao

  • # 77
    pleg
     scrive: 

    @yossarian

    Figurati, piacere mio!

  • # 78
    biffuz
     scrive: 

    Insomma, sto cercando di spiegare che i T1 e i T2 non soddisfano le esigenze dei più importanti clienti Sun, e per questo sta tornando sui suoi passi.
    Se poi andrebbero bene per altri, buon per loro… evidentemente non sono clienti importanti per la Sun.

Scrivi un commento!

Aggiungi il commento, oppure trackback dal tuo sito.

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.