  Beowulf HOWTO
  Jacek Radajewski and Douglas Eadline
  v1.1.1, 22 Novembre 1998

  Questo documento introduce l'architettura Beowulf per Supercomputer e
  fornisce informazioni di base sulla programmazione parallela, insieme
  a link ad altri documenti pi specifici e pagine web.  Documentazione
  tradotta dall'HackLab di Firenze (hacklab@firenze.linux.it).
  ______________________________________________________________________

  Indice Generale



  1. Introduzione
     1.1 Liberatoria
     1.2 Copyright
     1.3 Note su questo HOWTO
     1.4 Note sugli autori
     1.5 Riconoscimenti

  2. Introduzione
     2.1 A chi  indirizzato questo HOWTO?
     2.2 Cos' un Beowulf?
     2.3 Classificazione

  3. Uno sguardo all'architettura
     3.1 A cosa assomiglia?
     3.2 Come usare gli altri nodi?
     3.3 In cosa Beowulf  differente da un COW ?

  4. Progetto del sistema
     4.1 Una breve rassegna sulla computazione parallela
     4.2 I metodi della computazione parallela
        4.2.1 Perch pi di una CPU?
        4.2.2 Il negozio della computazione parallela
           4.2.2.1 Sistema operativo Single-tasking
           4.2.2.2 Sistemi operativi Multi-tasking:
           4.2.2.3 Sistemi operativi Multitasking con pi CPU:
           4.2.2.4 Thread su un sistema operativo multitasking con pi CPU:
           4.2.2.5 Invio di messaggi su sistemi operativi multitasking con pi CPU:
     4.3 Architetture per la computazione parallela
        4.3.1 Architetture Hardware
        4.3.2 Architetture API software
           4.3.2.1 Messaggi
           4.3.2.2 Thread
        4.3.3 Architettura dell'applicazione
     4.4 Fattibilit
     4.5 Scrittura e porting di software parallelo
        4.5.1 Determinare le parti concorrenti di un programma
        4.5.2 Stima dell'efficienza parallela
        4.5.3 Descrizione delle parti concorrenti di un programma
           4.5.3.1 Metodi espliciti In pratica l'utente deve specificatamente modificare il codice sorgente per un computer parallelo. L'utente deve aggiungere messaggi usando AURL CDATA http://www.epm.ornl.gov/pvmANAME CDATA PVM(HTMLURL)HTMLURL o AURL CDATA http://www.mcs.anl.gov/Projects/mpi/index.htmlANAME CDATA MPI(HTMLURL)HTMLURL o aggiungere thread usando i thread POSIX (occorre ricordare, per, che i thread non si possono muovere fra piastre madri SMP).
           4.5.3.2 Metodi Impliciti

  5. Risorse per Beowulf
     5.1 Per cominciare
     5.2 Documentazione
     5.3 Documenti cartacei
     5.4 Software
     5.5 Macchine Beowulf
     5.6 Altri siti interessanti
     5.7 Storia

  6. Codice sorgente
     6.1 sum.c
     6.2 sigmasqrt.c
     6.3 prun.sh


  ______________________________________________________________________

  11..  IInnttrroodduuzziioonnee

  11..11..  LLiibbeerraattoorriiaa

  Non ci possiamo assumere alcuna responsabilit per qualsiasi
  informazione sbagliata contenuta in questo documento, n per qualsiasi
  danno provocato dal suo uso.

  11..22..  CCooppyyrriigghhtt

  Copyright  1997 - 1998 Jacek Radajewski e Douglas Eadline.  La
  possibilit di distribuire e modificare questo documento  garantita
  dalla GNU General Public Licence.


  11..33..  NNoottee ssuu qquueessttoo HHOOWWTTOO

  Jacek Radajewski inizi a lavorare su questo documento nel Novembre
  del 1997 e fu subito aiutato da Douglas Eadline. Dopo pochi mesi il
  Beowulf HOWTO divenne troppo grande e nell'Agosto 1998 venne diviso in
  tre documenti: il Beowulf HOWTO, il Beowulf Architecture Design HOWTO,
  and the Beowulf Installation and Administration HOWTO. La versione
  1.0.0 del Beowulf HOWTO venne rilasciato al Linux Documentation
  Project l'11 Novembre 1998. Noi speriamo che questo sia solo l'inizio
  di ci che dovrebbe diventare un completo Beowulf Documentation
  Project.


  11..44..  NNoottee ssuuggllii aauuttoorrii


    Jacek Radajewski lavora come Amministratore di Rete e sta studiando
     per la laurea in informatica all'Universit di Southern Queensland,
     in Australia. Il suo primo approccio con Linux avvenne nel 1995 e
     fu subito amore a prima vista. Jacek ha costruito il suo primo
     cluster Beowulf nel Maggio del 1997 e sta giocando con questa
     tecnica da allora, cercando continuamente di trovare nuovi e
     migliori modi per impostare il tutto. Pu essere contattato
     all'indirizzo jacek@usq.edu.au

    Douglas Eadline, Ph.D.  il Presidente e Direttore della Ricerca a
     Paralogic, Inc., Bethlehem, PA, USA. Ha studiato come Chimico
     Fisico/Analitico e si  interessato ai computer fin dal 1978 quando
     costru il suo primo computer per usarlo con le strumentazioni
     chimiche.  I suoi attuali interessi sono Linux, i cluster Beowulf e
     gli algoritmi paralleli. Pu essere raggiunto all'indirizzo
     deadline@plogic.com


  11..55..  RRiiccoonnoosscciimmeennttii

  La stesura del Beowulf HOWTO  stato un processo lungo ed  finalmente
  completo, grazie a molte persone. Voglio ringraziare le seguenti
  persone per il loro aiuto e i loro contributi a questo HOWTO.

    Becky per il suo amore, supporto e comprensione.

    Tom Sterling, Don Becker e altre persone alla NASA che hanno
     iniziato il progetto Beowulf.

    Thanh Tran-Cong e la Facolt di Ingegneria e Controllo per aver
     reso disponibile per gli esperimenti la macchina Beowulf _t_o_p_c_a_t.

    Il mio tutor Christopher Vance per molte grandi idee.

    Il mio amico Russell Waldron per le grandi idee, il suo interesse
     generale nel progetto e l'aiuto.

    Il mio amico David Smith per aver controllato questo documento.

    Le molte persone della lista Beowulf che mi hanno dato feedback e
     idee.


    Tutte le persone curatrici del sistema operativo Linux e di tutti i
     programmi di software libero usati su _t_o_p_c_a_t e altre macchine
     Beowulf.


  22..  IInnttrroodduuzziioonnee


  Via via che le prestazioni dei computer comuni e dell'hardware di rete
  crescono, e il loro prezzo cala, diventa via via sempre pi facile
  costruire sistemi di calcolo parallelo dai componenti di facile
  reperibilit invece che comprare tempi CPU sui Supercomputer molto
  costosi. In effetti il rapporto costo e prestazioni di una macchina di
  tipo Beowulf  dalle tre alle dieci volte migliore che nei
  tradizionali Supercomputer. L'architettura Beowulf  scalabile, 
  facile da realizzare e si deve pagare solo l'hardware in quanto gran
  parte del software  gratuito.


  22..11..  AA cchhii  iinnddiirriizzzzaattoo qquueessttoo HHOOWWTTOO??

  Questo HOWTO  adatto per persone che abbiano un po' di esperienza con
  il sistema operativo Linux. La conoscenza della tecnologia Beowulf o
  la comprensione di sistemi operativi pi complessi e concetti di
  networking non  essenziale, ma qualche esperienza con il calcolo
  parallelo potrebbe essere utile (d'altronde dovresti avere qualche
  ragione per leggere questo documento). Questo HOWTO non risponde a
  tutte le domande che potrebbero sorgere su Beowulf, ma noi speriamo
  che possa darti buone idee e guidarti nella giusta direzione. Lo scopo
  di questo HOWTO  di dare informazioni iniziali, link e riferimenti a
  documenti pi avanzati.


  22..22..  CCooss'' uunn BBeeoowwuullff??


  _F_a_m_e_d _w_a_s _t_h_i_s _B_e_o_w_u_l_f_: _f_a_r _f_l_e_w _t_h_e _b_o_a_s_t _o_f _h_i_m_, _s_o_n _o_f _S_c_y_l_d_, _i_n
  _t_h_e _S_c_a_n_d_i_a_n _l_a_n_d_s_.  _S_o _b_e_c_o_m_e_s _i_t _a _y_o_u_t_h _t_o _q_u_i_t _h_i_m _w_e_l_l _w_i_t_h _h_i_s
  _f_a_t_h_e_r_'_s _f_r_i_e_n_d_s_, _b_y _f_e_e _a_n_d _g_i_f_t_, _t_h_a_t _t_o _a_i_d _h_i_m_, _a_g_e_d_, _i_n _a_f_t_e_r
  _d_a_y_s_, _c_o_m_e _w_a_r_r_i_o_r_s _w_i_l_l_i_n_g_, _s_h_o_u_l_d _w_a_r _d_r_a_w _n_i_g_h_, _l_i_e_g_e_m_e_n _l_o_y_a_l_: _b_y
  _l_a_u_d_e_d _d_e_e_d_s _s_h_a_l_l _a_n _e_a_r_l _h_a_v_e _h_o_n_o_r _i_n _e_v_e_r_y _c_l_a_n_.



  Beowulf  il pi  antico poema epico scritto in inglese arrivato fino
  a noi.  la storia di un eroe di grande forza e coraggio che sconfisse
  un mostro chiamato Grendel. Vai a ``Storia'' per saperne di pi
  dell'eroe Beowulf.



  Probabilmente ci sono tante definizioni di Beowulf quante sono le
  persone che realizzano o usano le caratteristiche dei Supercomputer
  Beowulf. Alcuni dicono che possono essere chiamati Beowulf solo i
  computer realizzati allo stesso modo della macchina originale della
  NASA. Altri invece vanno all'estremo e chiamano Beowulf tutti i
  sistemi di workstation che fanno girare codice parallelo. La mia
  definizione di Beowulf sta da qualche parte nel mezzo fra questi due
  modi di vedere ed  basata su molti messaggi della lista Beowulf:



  Beowulf  un'architettura a multicomputer che pu essere usata per
  calcoli paralleli.  un sistema che normalmente consiste di un nodo
  server e uno o pi nodi client connessi via Ethernet o altri tipi di
  rete.  un sistema costruito usando componenti hardware comuni, come
  qualunque PC che pu far girare Linux, normali adattatori Ethernet e
  switch. Non contiene alcun componente hardware speciale ed 
  facilmente realizzabile. Beowulf utilizza inoltre software comune come
  il sistema operativo Linux, Parallel Virtual Machine (PVM) e Message
  Passing Interface (MPI). Il nodo server controlla tutto il cluster e
  fornisce i file ai nodi client.  anche la console del cluster e il
  gateway con il mondo circostante. Grandi macchine Beowulf possono
  avere pi di un nodo server e  possibilmente altri nodi dedicati a
  compiti particolari, come per esempio console o stazioni di
  monitoraggio. In molti casi i nodi client in un sistema Beowulf sono
  dedicati al lavoro per il Beowulf, pi sono dedicati meglio . I nodi
  sono configurati e controllati dal nodo server, e fanno solo ci che
  gli viene detto. In una configurazione disk-less (senza dischi), i
  nodi client non conoscono nemmeno il loro indirizzo IP n il nome
  finch il server glielo comunica. Una delle differenze principali fra
  il Beowulf e il Cluster di Workstation (COW)  il fatto che Beowulf si
  comporta pi come una macchina singola che le molte workstation. In
  molti casi i client non hanno tastiere o monitor, e vi si accede solo
  via login remoto o possibilmente terminali seriali.  Un nodo Beowulf
  pu essere pensato come un pacchetto composto da CPU e memoria che pu
  essere inserito nel cluster, proprio come una CPU o un modulo di
  memoria possono essere infilati in una scheda madre.



  Beowulf non  un nuovo pacchetto software, un nuovo tipo di rete o
  l'ultima versione di sviluppo del kernel. Beowulf  un tecnica di
  clustering di computer con Linux per formare un supercomputer
  parallelo virtuale.  Inoltre ci sono molti pacchetti software come
  modifiche al kernel, le librerie PVM e MPI e programmi di
  configurazione che rendono l'architettura Beowulf pi veloce, pi
  facile da configurare e molto pi usabile; si pu creare una macchina
  di classe Beowulf usando distribuzioni Linux standard senza alcun
  software addizionale. Se avete due computer Linux in rete che
  condividono al limite il file system /home via NFS e permettono di
  eseguire shell remote (rsh), allora si pu pensare di avere una
  semplice macchina Beowulf composta da due nodi.


  22..33..  CCllaassssiiffiiccaazziioonnee


  I sistemi Beowulf sono stati realizzati da una gran variet di parti.
  Per favorire le prestazioni sono stati usati alcuni componenti non
  comuni (cio prodotti da una singola ditta). Per contare i differenti
  sistemi e per rendere la spiegazione delle macchine un po' pi
  semplice, noi proponiamo questo semplice schema di classificazione:


  BEOWULF DI CLASSE I:


  Questa classe di macchine costruita interamente da componenti comuni
  di facile reperibilit. Noi useremo il test di certificazione di
  "Computer Shopper" per definire i componenti comuni di facile
  reperibilit (Computer Shopper  una rivista/catalogo mensile spessa
  un pollice di sistemi e componenti per PC). Il test  questo:

  Un Beowulf di CLASSE I  una macchina che pu essere realizzata da
  componenti trovabili in almeno 3 cataloghi pubblicitari a carattere
  nazionale o globale.

  I vantaggi di un sistema di CLASSE I sono:

    l'hardware  reperibile da molte fonti (bassi prezzi e facile
     manutenzione)
    non c' dipendenza da un singolo rivenditore di hardware

    supporto dei driver dei prodotti Linux

     basato normalmente su standard (SCSI, Ethernet, ecc.)

  Gli svantaggi di un sistema di CLASSE I sono:

    maggiori prestazioni possono richiedere un hardware di CLASSE II

  Beowulf di CLASSE II

  Un Beowulf di CLASSE II  semplicemente qualsiasi macchina che non
  soddisfa il test di certificazione di Computer Shopper. Questa non 
  una cosa brutta.  semplicemente una classificazione della macchina.

  I vantaggi di un sistema di CLASSE II sono:

    Le prestazioni possono essere abbastanza buone!

  Gli svantaggi di un sistema di CLASSE II sono:

    il supporto dei driver pu variare

    dipendenza da un singolo rivenditore hardware

    possono essere molto pi costosi di un sistema di CLASSE I.

  Una CLASSE non  necessariamente migliore dell'altra, Tutto dipende
  dalle tue necessit e dal tuo budget. Questa classificazione serve
  solo a rendere la spiegazione dei sistemi Beowulf un po' pi breve. La
  sezione  ``Progetto del sistema'' ti pu aiutare a determinare che
  tipo di sistema si adatta alle tue necessit.



  33..  UUnnoo ssgguuaarrddoo aallll''aarrcchhiitteettttuurraa



  33..11..  AA ccoossaa aassssoommiigglliiaa??


  Io credo che il miglior modo per descrivere l'architettura del
  supercomputer Beowulf  quello di usare un esempio molto simile al
  Beowulf reale ma molto familiare a molti amministratori di sistema.
  L'esempio pi vicino ad una macchina Beowulf  un laboratorio Unix con
  un server e un certo numero di client. Per essere ancora pi precisi
  user come esempio il laboratorio di computer DEC Alpha per laureandi
  della facolt di Scienze dell'USQ. Il computer server si chiama _b_e_l_d_i_n
  e le macchine client sono chiamate _s_c_i_l_a_b_0_1, _s_c_i_l_a_b_0_2, _s_c_i_l_a_b_0_3, fino
  a _s_c_i_l_a_b_2_0. Tutti i client hanno installata una copia locale del
  sistema operativo Digital Unix 4.0 ma condividono la directory degli
  utenti /home e la directory /usr/local dal server via NFS (Network
  File System). Ogni client ha una voce per il server e una per ognuno
  degli altri client nel suo file /etc/hosts.equiv, cos che ogni client
  pu eseguire una shell remota (rsh) in tutti gli altri. La macchina
  server  anche server NIS per tutto il laboratorio, cos che tutti gli
  account sono comuni in tutte le macchine. Una persona pu sedersi
  davanti alla console di _s_c_i_l_a_b_0_2 ed avere la stessa configurazione
  come se si fosse fatto il login nel server o nel client _s_c_i_l_a_b_1_5. La
  ragione per la quale tutti i client hanno lo stesso look and feel 
  che il sistema operativo  installato e configurato allo stesso modo
  su tutte le macchine e che sia /home che /usr/local sono fisicamente
  sul server e condivise da tutti i client via NFS. Per maggiori
  informazioni a proposito di NIS e NFS guardate i relativi HOWTO a NIS
  e NFS.



  33..22..  CCoommee uussaarree ggllii aallttrrii nnooddii??


  Ora che abbiamo un'idea circa l'architettura del sistema, diamo
  un'occhiata a come possiamo utilizzare i cicli di CPU disponibili nei
  computer del laboratorio. Ogni persona pu fare il login in ogni
  macchina, e far girare un programma nella sua directory home, ma pu
  anche distribuire il lavoro su macchine differenti semplicemente
  eseguendo shell remote. Per esempio, mettiamo che vogliamo calcolare
  la somma delle radici quadrate di tutti gli interi compresi fra 1 e
  10.  Scriviamo un programma chiamandolo sigmassqrt (vedi ``Codice
  sorgente'') che fa proprio questo. Per calcolare la somma delle radici
  quadrate dei numeri da 1 a 10 noi eseguiamo:


  [jacek@beldin sigmasqrt]$ time ./sigmasqrt 1 10 22.468278

  real    0m0.029s
  user    0m0.001s
  sys     0m0.024s



  Il comando time ci permette di controllare il tempo trascorso per
  completare l'altro comando. Come possiamo vedere, questo esempio ha
  necessitato solo una frazione di secondo (0,029 sec), ma cosa
  succederebbe se io volessi conoscere la somma delle radici quadrate
  degli interi compresi fra 1 e 1 000 000 000 (un miliardo)? Riproviamo
  e ricontrolliamo il tempo necessario.


  [jacek@beldin sigmasqrt]$ time ./sigmasqrt 1 1000000000
  21081851083600.559000

  real    16m45.937s
  user    16m43.527s
  sys     0m0.108s



  Questa volta il tempo di esecuzione  decisamente maggiore. L'ovvia
  domanda che sorge  cosa possiamo fare per abbreviare il tempo di
  esecuzione di questo programma? Come possiamo cambiare il modo in cui
  si esegue questo programma per ridurne il tempo di esecuzione? L'ovvia
  risposta  quella di dividere il lavoro in una serie di sotto-compiti
  e di farli girare in parallelo su tutti i computer. Noi possiamo
  dividere il calcolo di una grossa addizione in 20 parti, calcolare una
  serie di radici quadrate e farli girare su ogni nodo. Quando tutti i
  nodi finiscono il calcolo e restituiscono i loro risultati, i 20
  numeri possono essere sommati per ottenere il risultato finale. Prima
  di far girare questo programma noi faremo una named pipe che verr
  usata da tutti i processi per scrivere il loro risultato.



  [jacek@beldin sigmasqrt]$ mkfifo output
  [jacek@beldin sigmasqrt]$ ./prun.sh & time cat output | ./sum
  [1] 5085
  21081851083600.941000
  [1]+  Done                    ./prun.sh

  real    0m58.539s
  user    0m0.061s
  sys     0m0.206s



  Il tempo che otteniamo  di circa 58,5 secondi. Questo  il tempo
  trascorso dall'inizio del programma fino alla restituzione all'interno
  della pipe dei risultati di tutti i nodi. Il tempo cos calcolato non
  include la somma finale dei venti numeri, ma questo tempo  molto
  breve e pu essere trascurato. Possiamo cos vedere che c' un
  notevole miglioramento eseguendo questo programma in parallelo. In
  effetti il programma parallelo ha girato 17 volte pi velocemente, che
   un buon risultato avendo incrementato di 20 volte il numero di CPU
  coinvolte.  Lo scopo di questo esempio  quello di far vedere il
  metodo pi semplice di realizzare codice parallelo concorrente. In
  pratica per esempi cos semplici sono rari ma vengono usate altre
  tecniche (le API PVM e PMI) per ottenere il parallelismo.


  33..33..  IInn ccoossaa BBeeoowwuullff  ddiiffffeerreennttee ddaa uunn CCOOWW ??


  Il laboratorio di computer descritto sopra  un perfetto esempio di un
  Cluster di Workstation (COW). E allora cosa ha tanto di speciale
  Beowulf e in cosa  diverso da un COW? La verit  che non c' una
  grande differenza, ma Beowulf ha alcune caratteristiche peculiari.
  Innanzitutto in molti casi i nodi client di un cluster Beowulf non
  hanno tastiere, mouse, schede video n monitor. Tutti gli accessi ai
  nodi client sono realizzati in remoto dal nodo server, nodi che
  fungono solo da console o da un terminale seriale. Poich non c'
  bisogno per i nodi client di accedere a computer al di fuori del
  cluster, n per computer esterni al cluster di accedere direttamente
  ai nc,  pratica comune dotare i nc di IP privati come gli indirizzi
  compresi in 10.0.0.0/8 o 192.168.0.0/16 (vedi RFC 1918
  http://www.alternic.net/rfcs/1900/rfc1918.txt.html). Normalmente
  l'unica macchina connessa all'esterno con una seconda scheda di rete 
  il nodo server. Il modo pi comune per usare un sistema di questo tipo
   di usare la console del ns, oppure di entrare in telnet o shell
  remota dal computer personale. Una volta sul ns, gli utenti possono
  modificare e compilare il loro codice e anche suddividere i loro
  programmi su tutti i nodi del cluster. In molti casi i COW sono usati
  per calcoli paralleli la notte e durante i fine settimana quando gli
  utenti non usano effettivamente i computer per i compiti di tutti i
  giorni, utilizzando cos cicli idle di CPU. Beowulf d'altra parte 
  una macchina dedicata normalmente solo al calcolo parallelo e
  ottimizzato per questo scopo. Beowulf inoltre ha un miglior rapporto
  fra prezzo e prestazioni poich  realizzato da componenti di facile
  reperibilit e usa normalmente software gratuito. Beowulf ha inoltre
  un'immagine pi da sistema singolo cosa che aiuta gli utenti a vedere
  un cluster Beowulf come una singola workstation


  44..  PPrrooggeettttoo ddeell ssiisstteemmaa


  Prima di acquistare dell'hardware,  sempre una buona idea prendere in
  considerazione il progetto del sistema che si intende realizzare.
  Fondamentalmente ci sono due questioni relative al progetto di un
  sistema Beowulf: il tipo di nodi (cio di computer) da usare e il modo
  in cui tali nodi sono connessi. C' una questione relativa al
  software, che pu influire sulle decisioni che riguardano l'hardware:
  la libreria di comunicazione (API). Nel seguito di questo documento
  verr fatta una discussione pi dettagliata riguardo all'hardware e al
  software di comunicazione.



  Anche se il numero di possibilit non  elevato, quando si costruisce
  un Beowulf, ci sono comunque alcune importanti decisioni di progetto
  da prendere. Poich la scienza (o l'arte) della "computazione
  parallela" ha molte interpretazioni differenti, qui di seguito ne
  viene data un'introduzione. Se non ti piace leggere materiale di
  rassegna, puoi saltare questa sezione, ma sei vivamente invitato a
  leggere la sezione ``Fattibilit'' prima di prendere le decisioni
  finali relative all'hardware.


  44..11..  UUnnaa bbrreevvee rraasssseeggnnaa ssuullllaa ccoommppuuttaazziioonnee ppaarraalllleellaa


  Questa sezione fornisce una rassegna sui concetti della computazione
  parallela.  NON  una descrizione completa n esauriente della scienza
  e tecnologia della computazione parallela.  una breve descrizione
  delle questioni che possono essere importanti per un progettista o per
  un utente Beowulf.



  Mentre progetti e costruisci il tuo Beowulf, molte delle questioni che
  vengono descritte sotto diventeranno importanti nel processo delle tue
  decisioni. A causa della natura dei suoi componenti, un supercomputer
  Beowulf richiede che si prendano attentamente in considerazione molti
  fattori che adesso vengono a essere sotto il nostro controllo. In
  generale, non  cos difficile comprendere le questioni relative alla
  computazione parallela. In realt, una volta che le questioni sono
  comprese, le tue aspettative saranno pi realistiche e avrai una
  maggiore probabilit di successo. A differenza del "mondo
  sequenziale", in cui la velocit del processore  considerato il solo
  fattore che ha la massima importanza, la velocit dei processori nel
  "mondo parallelo"  solo uno dei vari fattori che determineranno le
  prestazioni e l'efficienza del sistema complessivo.



  44..22..  II mmeettooddii ddeellllaa ccoommppuuttaazziioonnee ppaarraalllleellaa


  La computazione parallela pu assumere molte forme. Dal punto di vista
  dell'utente  importante considerare vantaggi e svantaggi di ciascuna
  metodologia. La sezione seguente tenta di dare diverse prospettive sui
  metodi della computazione parallela e indica dove va a cadere una
  macchina Beowulf all'interno di questo continuum.



  44..22..11..  PPeerrcchh ppii ddii uunnaa CCPPUU??


   importante rispondere a questa domanda. Usare 8 CPU per eseguire un
  word processor suona un po' "over-kill" -- e in effetti lo . Ma cosa
  dire di un server web, una base di dati, un programma di rendering o
  uno schedulatore di progetti? Forse pi CPU potrebbero essere d'aiuto.
  E cosa dire di una simulazione complessa, un codice che studia la
  dinamica dei fluidi, o un'applicazione di estrazione di dati? In
  queste situazioni, pi CPU sono sicuramente d'aiuto. In effetti,
  sistemi con CPU multiple vengono usati per risolvere sempre pi
  problemi.



  Generalmente la successiva domanda : "Perch ho bisogno di due o
  quattro CPU? Aspetter semplicemente il chip iper-turbo 986." Ci sono
  varie ragioni:


  1. Grazie all'uso di sistemi operativi multi-tasking,  possibile fare
     pi cose alla volta. Questo  un "parallelismo" naturale che 
     facilmente sfruttato da pi CPU a basso costo.

  2. La velocit dei processori va raddoppiando ogni 18 mesi, ma cosa
     dire delle velocit delle RAM e degli hard disk? Purtroppo, queste
     velocit non stanno aumentando velocemente cos come quelle delle
     CPU.  Si tenga presente che la maggior parte delle applicazioni
     richiedono "accessi in memoria fuori cache" e accessi agli hard
     disk. Un modo per aggirare alcune di queste limitazioni consiste
     nel fare pi cose in parallelo.

  3. Le previsioni indicano che le velocit dei processori non
     continueranno a raddoppiare ogni 18 mesi dopo l'anno 2005. Per
     poter mantenere questa tendenza ci sono alcuni ostacoli molto ardui
     da superare.

  4. A seconda dell'applicazione, la computazione parallela pu
     velocizzare l'esecuzione di un fattore da 2 a 500 volte (in qualche
     caso anche di pi). Tali performance non sono disponibili usando un
     singolo processore. Anche i supercomputer che un tempo usavano
     processori molto veloci, adesso sono costruiti utilizzando pi CPU
     reperibili comunemente.

  Se hai bisogno di velocit - sia a causa di un problema di limiti
  della computazione che di un problema di limiti nell'I/O, vale la pena
  considerare il parallelismo. Poich la computazione parallela 
  implementata in vari modi, per risolvere il tuo problema con il
  parallelismo dovranno essere prese alcune decisioni molto importanti.
  Queste decisioni possono avere effetti decisivi sulla portabilit, la
  performance e il costo della tua applicazione.



  Prima di entrare nei dettagli tecnici, diamo uno sguardo a un
  "problema di computazione parallela" reale, usando un esempio con il
  quale abbiamo familiarit: l'attesa in lunghe code a un negozio.


  44..22..22..  IIll nneeggoozziioo ddeellllaa ccoommppuuttaazziioonnee ppaarraalllleellaa


  Immaginiamo un grande negozio con 8 registratori di cassa raggruppati
  insieme nella parte anteriore del negozio.  Assumiamo che ogni
  cassiere/registratore corrisponda a una CPU e ogni cliente a un
  programma di computer. La dimensione del programma di computer (il
  carico di lavoro) corrisponde alla dimensione della spesa del cliente.
  Per illustrare i concetti della computazione parallela possono essere
  usate le seguenti analogie.



  44..22..22..11..  SSiisstteemmaa ooppeerraattiivvoo SSiinnggllee--ttaasskkiinngg


  Un solo registratore di cassa  aperto (in uso) e deve servire ogni
  cliente, uno alla volta.


  Esempio relativo ai computer: MS DOS



  44..22..22..22..  SSiisstteemmii ooppeerraattiivvii MMuullttii--ttaasskkiinngg::


  Un solo registratore di cassa  aperto, ma adesso viene servita solo
  una parte di una spesa per volta, si passa al prossimo cliente e si
  serve una parte della sua spesa. I clienti "sembrano" muoversi lungo
  la coda insieme, ma se oltre a te non ci sono altri clienti, verrai
  servito pi velocemente.


  Esempio relativo ai computer: UNIX, NT utilizzante una singola CPU



  44..22..22..33..  SSiisstteemmii ooppeerraattiivvii MMuullttiittaasskkiinngg ccoonn ppii CCPPUU::


  Adesso apriamo pi registratori di cassa nel negozio. Ogni cliente pu
  essere servito da un registratore di cassa separato e la coda pu
  muoversi pi velocemente. Questa viene chiamata SMP - Multi-
  elaborazione simmetrica (Symmetric Multi-processing). Sebbene ci siano
  pi registratori di cassa aperti, continuerai a non muoverti lungo la
  coda pi velocemente del caso in cui ci sei solo tu e un solo
  registratore di cassa.


  Esempio relativo ai computer: UNIX e NT con pi CPU



  44..22..22..44..  TThhrreeaadd ssuu uunn ssiisstteemmaa ooppeerraattiivvoo mmuullttiittaasskkiinngg ccoonn ppii CCPPUU::


  Se "spezzi" gli articoli della tua spesa, puoi muoverti pi
  velocemente sulla coda usando pi registratori di cassa allo stesso
  tempo.  Innanzitutto, dobbiamo ipotizzare un gran guadagno, perch il
  tempo investito nello "spezzare la spesa" deve essere riguadagnato
  usando pi registratori di cassa. In teoria, dovresti muoverti lungo
  la coda "n" volte pi veloce di prima, dove "n"  il numero di
  registratori di cassa.  Quando i cassieri hanno bisogno dei totali
  parziali, possono scambiarsi velocemente informazioni guardando e
  parlando a ogni altro registratore di cassa "locale". Possono anche
  curiosare ai registratori di cassa vicini per cercare informazioni di
  cui hanno bisogno per lavorare pi velocemente. Comunque, c' un
  limite al numero di registratori di cassa che possono trovarsi in un
  punto del negozio.

  La legge di Amdal, inoltre, limiter la velocit dell'applicazione
  alla porzione sequenziale del programma pi lenta.

  Esempio relativo ai computer: UNIX oppure NT con extra CPU sulla
  stessa scheda madre che eseguono programmi multi-threaded.



  44..22..22..55..  IInnvviioo ddii mmeessssaaggggii ssuu ssiisstteemmii ooppeerraattiivvii mmuullttiittaasskkiinngg ccoonn ppii
  CCPPUU::


  Al fine di migliorare la performance, il negozio aggiunge 8
  registratori di cassa sul retro del negozio. Poich i nuovi
  registratori di cassa sono lontani da quelli che si trovano sul
  davanti, i cassieri devono chiamare questi al telefono per comunicare
  i loro totali parziali. Tale distanza aggiunge un sovraccarico (di
  tempo) alla comunicazione tra cassieri, ma se le comunicazioni sono
  minimizzate, ci non costituisce un problema. Se fai una spesa davvero
  molto grande, tale da richiedere tutti i registratori di cassa,
  allora, come avveniva prima, la velocit pu essere aumentata usando
  tutti i registratori di cassa allo stesso tempo, e il sovraccarico va
  riconsiderato. In qualche caso, il negozio pu avere singoli
  registratori di cassa (o gruppi isolati di registratori di cassa)
  sparsi per il negozio: ogni registratore di cassa (o isola) deve
  comunicare via telefono. Poich tutti i cassieri possono comunicare
  l'un l'altro attraverso il telefono, non  molto importante dove si
  trovano.

  Esempio relativo ai computer: una o pi copie di UNIX o NT con pi CPU
  sulla stessa o su differenti schede madri, che comunicano attraverso
  messaggi.

  Gli scenari descritti sopra, sebbene non esatti, sono una buona
  rappresentazione dei vincoli posti sui sistemi paralleli. A differenza
  di sistemi con singola CPU (o registratore di cassa), qui va presa in
  considerazione la possibilit di comunicazione tra diverse CPU.


  44..33..  AArrcchhiitteettttuurree ppeerr llaa ccoommppuuttaazziioonnee ppaarraalllleellaa


  Di seguito vengono presentati i metodi e le architetture comuni della
  computazione parallela. Sebbene la presente trattazione non sia
  sicuramente esauriente,  sufficiente per comprendere le questioni
  fondamentali relative a un progetto Beowulf.


  44..33..11..  AArrcchhiitteettttuurree HHaarrddwwaarree


  Ci sono fondamentalmente due modi in cui viene messo insieme
  l'hardware dei computer paralleli:


  1. Macchine con memoria locale che comunicano mediante messaggi
     (clusters Beowulf)

  2. Macchine con memoria condivisa che comunicano attraverso la memoria
     (macchine SMP)

  Un tipico Beowulf  un insieme di macchine con singola CPU, connesse
  usando fast Ethernet ed , pertanto, una macchina a memoria locale.
  Una macchina SMP a 4 vie  una macchina a memoria condivisa e pu
  essere usata per fare computazioni parallele - applicazioni parallele
  che comunicano usando la memoria condivisa. Proprio come nell'esempio
  dell'analogia negozio-computer, le macchine a memoria locale
  (registratori di cassa individuali) possono essere scalati a grandi
  numeri di CPU, mentre il numero di CPU in macchine a memoria condivisa
  (il numero di registratori di cassa che si possono mettere in un
  punto) pu essere limitato a causa di conflitti nell'accesso alla
  memoria.


   possibile, comunque, connettere molte macchine a memoria condivisa
  per creare una macchina a memoria condivisa "ibrida". Queste macchine
  ibride "appaiono" all'utente come una grande macchina SMP singola e
  sono spesso chiamate macchine NUMA (accesso in memoria non uniforme),
  perch la memoria globale vista dal programmatore e condivisa da tutte
  le CPU pu avere differenti ritardi. A qualche livello, comunque, una
  macchina NUMA deve "inviare messaggi" tra gruppi di memorie localmente
  condivise.

   anche possibile connettere macchine SMP come nodi di computazione a
  memoria locale. Le tipiche schede madri della CLASSE I hanno 2 o 4 CPU
  e sono usate spesso come un mezzo per ridurre il costo del sistema
  complessivo. Lo schedulatore interno di Linux determina come queste
  CPU ottengono le risorse condivise. L'utente non pu (a questo punto)
  assegnare uno specifico task a uno specifico processore SMP. L'utente
  pu, comunque, iniziare due processi indipendenti oppure un processo
  multithreaded e aspettarsi un aumento di performance rispetto a un
  sistema avente una singola CPU.


  44..33..22..  AArrcchhiitteettttuurree AAPPII ssooffttwwaarree


  Ci sono fondamentalmente due modi per "esprimere" la concorrenza in un
  programma:


  1. Usare l'invio di messaggi tra processori

  2. Usare i thread del sistema operativo


  Esistono altri metodi, ma questi due sono quelli pi largamente usati.
   importante ricordare che l'espressione della concorrenza non 
  necessariamente controllata dall'hardware sottostante. Sia lo scambio
  di messaggi che i thread possono essere implementati su SMP, NUMA-SMP
  e cluster - sebbene, come spiegato sotto, l'efficienza e la
  portabilit sono questioni importanti.



  44..33..22..11..  MMeessssaaggggii


  Storicamente, la tecnologia dello scambio di messaggi rifletteva il
  modello dei primi computer paralleli a memoria locale. I messaggi
  richiedono un'operazione di copia dei dati, mentre i thread,
  corrispondentemente, usano dati. I ritardi e le velocit alle quali i
  messaggi possono essere copiati sono i fattori limitanti dei modelli a
  scambio di messaggi. Un messaggio  piuttosto semplice: qualche dato e
  un processore destinatario. Le API comuni per lo scambio di messaggi
  sono PVM oppure MPI. Lo scambio di messaggi pu essere implementato
  efficientemente usando i thread, quindi i messaggi funzionano bene sia
  su macchine SMP che tra cluster di macchine. Il vantaggio nell'uso dei
  messaggi su una macchina SMP, invece del normale uso dei thread,  che
  se decidi in futuro di usare cluster,  facile aggiungere macchine o
  scalare le tue applicazioni.



  44..33..22..22..  TThhrreeaadd


  I thread del sistema operativo sono stati sviluppati poich i progetti
  di SMP (multi-elaborazione simmetrica) a memoria condivisa
  consentivano una comunicazione e sincronizzazione molto veloci, tra
  parti concorrenti di un programma. I thread funzionano bene su sistemi
  SMP perch la comunicazione avviene attraverso la memoria condivisa.
  Per questa ragione l'utente deve isolare i dati locali da quelli
  globali, altrimenti i programmi non gireranno nel modo corretto. A
  differenza dei messaggi, con i thread una buona parte di copiatura pu
  essere evitata, perch i dati sono condivisi dai processi (thread).
  Linux supporta i thread POSIX. Il problema con i thread  che 
  difficile estenderli oltre una macchina SMP e poich i dati sono
  condivisi dalle CPU, le questioni relative alla coerenza delle cache
  pu contribuire al sovraccarico.  Estendere i thread oltre i limiti
  della SMP in modo efficiente richiede la tecnologia NUMA che  costosa
  e non supportata da Linux in forma nativa. I thread sono stati
  implementati sopra i messaggi
  ((http://syntron.com/ptools/ptools_pg.htm)), ma i thread implementati
  usando i messaggi sono spesso inefficienti.



  Riguardo alla performance si pu affermare quanto segue:



                 performance di       performance di un         scalabilit
                 una macchina SMP     cluster di macchine
                 ----------------     -------------------       -----------
  messaggi       buona                ottima                    ottima

  thread         ottima               scarsa*                   scarsa*

  * richiede una tecnologia NUMA costosa.



  44..33..33..  AArrcchhiitteettttuurraa ddeellll''aapppplliiccaazziioonnee


  Per poter eseguire un'applicazione in parallelo su pi CPU, occorre
  suddividerla in parti concorrenti. Un'applicazione progettata per una
  singola CPU, non verr eseguita pi velocemente di un'applicazione per
  singola CPU su una macchina multiprocessore.

  Ci sono alcuni strumenti e compilatori che possono suddividere i
  programmi, ma parallelizzare il codice, non  un'operazione
  "plug'n'play". A seconda del tipo di applicazione, parallelizzare il
  codice pu essere facile, estremamente difficile o addirittura
  impossibile, in base alle dipendenze dell'algoritmo.



  Prima di affrontare la questione del software, occorre introdurre il
  concetto di Fattibilit.


  44..44..  FFaattttiibbiilliitt


  Molte domande relative all'elaborazione parallela, hanno la stessa
  risposta:



  "Dipende dall'applicazione"


  Prima di addentrarsi nel problema, c' un'importante distinzione da
  fare - la differenza tra CONCORRENTE e PARALLELO.  Per il gusto della
  discussione definiremo cos questi due concetti:



  CONCORRENTI: parti di un programma che possono essere eseguite
  indipendentemente.



  PARALLELE:  parti CONCORRENTI di un programma eseguite da processori
  diversi nello stesso momento.



  La distinzione  molto importante, poich la CONCORRENZA  una
  propriet del programma, mentre il PARALLELISMO  una propriet della
  macchina.  Idealmente un'esecuzione parallela dovrebbe risultare in
  prestazioni pi veloci. Il fattore limitante nelle prestazioni
  parallele  la velocit di comunicazione e la latenza fra i nodi (la
  latenza esiste anche con applicazioni i cui thread sono eseguiti su
  CPU diverse, a causa della necessit di controllare la coerenza della
  cache - cache coherency).  Molti dei comuni benchmark paralleli sono
  altamente paralleli, quindi latenza e comunicazione non costituiscono
  colli di bottiglia. Questo tipo di problema pu essere chiamato
  "ovviamente parallelo". Altre applicazioni non sono cos semplici ed
  eseguire parti CONCORRENTI del programma in PARALLELO potrebbe causare
  un rallentamento del programma, vanificando cos ogni miglioramento di
  prestazioni ottenuto nelle parti CONCORRENTI del programma. In altre
  parole, il tempo di comunicazione impiegato deve essere proporzionato
  con quello impiegato nell'elaborazione, altrimenti l'esecuzione
  PARALLELA di parti CONCORRENTI  inefficiente.



   compito del programmatore determinare quali parti CONCORRENTI del
  programma devono essere eseguite in PARALLELO e quali NO. La risposta
  a ci determiner l'EFFICIENZA dell'applicazione. Il grafico che
  segue, riassume la situazione per il programmatore:



           | *
           | *
           | *
   % di    | *
   appli-  |  *
   cazione |  *
           |  *
           |  *
           |    *
           |     *
           |      *
           |        ****
           |            ****
           |                ********************
           +-----------------------------------
            tempo di comunicazione/tempo di elaborazione



  In un perfetto computer parallelo, il rapporto fra comunicazione e
  elaborazione sarebbe uguale, e tutto ci che fosse CONCORRENTE
  potrebbe essere implementato in PARALLELO. Sfortunatamente computer
  paralleli reali, incluse macchine con memoria condivisa, sono soggette
  agli effetti descritti nel grafico. Chi progetta un Beowulf, tenga in
  mente questo grafico, perch l'efficienza dell'elaborazione parallela
  dipende dal rapporto fra tempo di comunicazione e tempo di
  elaborazione per UNO SPECIFICO COMPUTER PARALLELO. Le applicazioni
  possono essere portabili fra computer paralleli, ma non c' garanzia
  che saranno efficienti su una piattaforma differente.



  IN GENERALE, NON ESISTE UN PROGRAMMA PARALLELO PORTABILE ED
  EFFICIENTE.



  C' ancora un'altra conseguenza del grafico di cui sopra. Poich
  l'efficienza dipende dal rapporto comunic./elab., cambiare un solo
  componente del rapporto non significa, necessariamente, che
  un'applicazione sar pi veloce. Un processore pi veloce, mantenendo
  la stessa velocit di comunicazione, potrebbe non avere effetti
  visibili sul programma. Per esempio, raddoppiando o triplicando la
  velocit della CPU, mantenendo la stessa velocit di comunicazione,
  potrebbe far s che alcune porzioni che prima erano eseguite in
  PARALLELO, adesso siano pi efficienti se eseguite SEQUENZIALMENTE.
  Quindi, adesso potrebbe essere pi veloce eseguire le parti che prima
  erano PARALLELE, come SEQUENZIALI.  Inoltre, una inefficiente
  esecuzione di porzioni parallele, impedir all'applicazione di
  raggiungere la sua massima velocit. Quindi l'aggiunta di un
  processore pi veloce potrebbe rallentare l'applicazione (impedendo
  alla nuova CPU di raggiungere la sua massima velocit, per
  quell'applicazione).



  SOSTITUIRE LA CPU CON UNA PI VELOCE, POTREBBE RALLENTARE
  L'APPLICAZIONE.



  In conclusione, quindi, per sapere se usare o no un'architettura
  parallela, occorre avere un po' di intuito circa l'adeguatezza di una
  particolare macchina per un'applicazione.  Occorre tener presente
  svariati fattori, incluso la velocit della CPU, il compilatore, le
  "message passing API", la rete, ecc. Inoltre occorre tener presente
  che l'aver tracciato lo schema di un'applicazione non  tutto.

   possibile identificare una porzione del programma in cui  richiesta
  una pesante elaborazione, ma non  possibile conoscerne il costo in
  termini di comunicazione. Potrebbe essere che, per un certo sistema, i
  costi di comunicazione rendano inefficiente l'esecuzione in parallelo
  del codice.



  Una nota finale su un malinteso comune. Spesso viene detto che un
  programma  PARALLELIZZATO, ma in realt solo le parti CONCORRENTI lo
  sono. Per tutte le ragioni dette sopra, il programma non 
  PARALLELIZZATO. Un'efficiente PARALLELIZZAZIONE  una propriet della
  macchina.



  44..55..  SSccrriittttuurraa ee ppoorrttiinngg ddii ssooffttwwaarree ppaarraalllleelloo


  Una volta stabilita la necessit della computazione parallela e quindi
  di costruire un Beowulf, potrebbe essere una buona idea ripensare
  all'applicazione in base a quanto detto precedentemente.



  In generale ci sono due cose che possono essere fatte:

  1. Andare avanti e costruire un Beowulf di classe I e quindi adattare
     ad esso l'applicazione. O eseguire applicazioni parallele che
     sappiamo funzioneranno su tale Beowulf (ma attenzione alla
     portabilit e all'efficienza di cui sopra).

  2. Studiare le applicazioni che verranno eseguite sul Beowulf e fare
     alcune stime sul tipo di hardware e software di cui c' bisogno.

  In altri casi, in qualche momento, occorrer prendere in
  considerazione i fattori relativi all'efficienza.

  In generale possono essere fatte tre cose:

  1. Determinare le parti concorrenti di un programma

  2. Stimare efficientemente le porzioni parallele

  3. Descrivere le parti concorrenti

  Esaminiamole una per una


  44..55..11..  DDeetteerrmmiinnaarree llee ppaarrttii ccoonnccoorrrreennttii ddii uunn pprrooggrraammmmaa


  Questo passo  spesso considerato come "parallelizzazione del
  programma".  Le decisioni sulle parallelizzazioni, verranno prese nel
  passo 2. In questo passo occorre determinare le data dependencies.



  Da un punto di vista pratico, le applicazioni possono esporre due tipi
  di concorrenza: pesanti elaborazioni (macina numeri, "number
  crunching") e I/O (database). Sebbene in molti casi la concorrenza di
  elaborazione e I/O sono ortogonali, ci sono applicazioni che li
  richiedono entrambi.  Esistono alcuni strumenti che possono effettuare
  una analisi di concorrenza sulle applicazioni esistenti.  La maggior
  parte di questi strumenti sono progettati per il FORTRAN. Due sono le
  ragioni per cui viene utilizzato il FORTRAN: storicamente la maggior
  parte di applicazioni che effettuano numerosi calcoli sono state
  scritte in FORTRAN ed  pi facile da analizzare. Se non ci sono
  strumenti disponibili, questo passo pu essere complicato, per le
  applicazioni esistenti.



  44..55..22..  SSttiimmaa ddeellll''eeffffiicciieennzzaa ppaarraalllleellaa


  Senza l'aiuto di strumenti, questo passo pu richiedere prove ed
  errori, o solo provare formulare delle ipotesi. Per ogni specifica
  applicazione occorre provare a determinare se ha dei limiti di CPU
  (legati all'elaborazione) o di hard disk (legati all'I/O). Le esigenze
  di Beowulf possono differire in base alle necessit. Per esempio un
  problema legato all'elaborazione pu aver bisogno di poche CPU molto
  veloci e una rete molto veloce, mentre un problema legato all'I/O pu
  funzionare meglio con pi CPU pi lente e una fast Ethernet.



  Questa raccomandazione, in genere,  una sorpresa per molte persone,
  perch  un luogo comune che i processori pi veloci sono sempre
  meglio.  Questo  vero se si dispone di un budget illimitato, i
  sistemi reali possono avere vincoli di costo che occorre valutare. Per
  i problemi legati all'I/O, c' una regola poco conosciuta (chiamata
  Legge Eadline-Dedkov) che  abbastanza utile:



  Poich due computer paralleli con lo stesso indice di prestazioni per
  la somma delle CPU, quello che ha i processori pi lenti (e
  probabilmente una corrispondente rete di comunicazione pi lenta fra i
  processori) avr prestazioni migliori per quelle applicazioni che
  fanno largo uso di I/O.



  Mentre la profondit di questa regola va oltre lo scopo di questo
  documento, potrebbe essere interessante scaricare il documento
  _P_e_r_f_o_r_m_a_n_c_e _C_o_n_s_i_d_e_r_a_t_i_o_n_s _f_o_r _I_/_O_-_D_o_m_i_n_a_n_t _A_p_p_l_i_c_a_t_i_o_n_s _o_n _P_a_r_a_l_l_e_l
  _C_o_m_p_u_t_e_r_s (Postscript format 109K)
  (ftp://www.plogic.com/pub/papers/exs-pap6.ps)



  Una volta determinato il tipo di concorrenza dell'applicazione,
  occorre stimare quanto possa essere efficiente in parallelo. Vedere la
  sezione ``Software'' per una descrizione degli strumenti Software.



  In assenza di strumenti, occorre provare ad ipotizzare la propria
  strada, in questa fase. Se un'elaborazione che richiede molta cpu pu
  essere misurata in minuti e i dati possono essere trasferiti in
  secondi, allora potrebbe essere una buona candidata per la
  parallelizzazione. Occorre ricordare, per, che se un loop di 16
  minuti viene suddiviso in 32 parti, il trasferimento dei dati richiede
  diversi secondi per parte, allora le cose potranno essere difficili.
  Si raggiunger un punto in cui i ritorni sono ridotti.



  44..55..33..  DDeessccrriizziioonnee ddeellllee ppaarrttii ccoonnccoorrrreennttii ddii uunn pprrooggrraammmmaa

  Ci sono diversi modi per descrivere le parti concorrenti di un
  programma:


  1. Esecuzione parallela esplicita

  2. Esecuzione parallela implicita

  La maggiore differenza fra le due  che l'esplicita  determinata
  dall'utente, mentre l'implicita  determinata dal compilatore.


  44..55..33..11..  MMeettooddii eesspplliicciittii IInn pprraattiiccaa ll''uutteennttee ddeevvee ssppeecciiffiiccaattaammeennttee
  mmooddiiffiiccaarree iill ccooddiiccee ssoorrggeennttee ppeerr uunn ccoommppuutteerr ppaarraalllleelloo.. LL''uutteennttee ddeevvee
  aaggggiiuunnggeerree mmeessssaaggggii uussaannddooPPVVMM ooMMPPII oo aaggggiiuunnggeerree tthhrreeaadd uussaannddoo ii tthhrreeaadd
  PPOOSSIIXX ((ooccccoorrrree rriiccoorrddaarree,, ppeerr,, cchhee ii tthhrreeaadd nnoonn ssii ppoossssoonnoo mmuuoovveerree
  ffrraa ppiiaassttrree mmaaddrrii SSMMPP))..


  I metodi espliciti sono i pi difficili da implementare e da mettere
  sotto debug. Gli utenti, in genere, includono chiamate a funzioni
  esplicite in sorgenti standard FORTRAN 77 o C/C++. Alla libreria MPI
  sono state aggiunte alcune funzioni per rendere pi facili da
  implementare alcuni metodi paralleli standard (ad es. le funzioni
  scatter/gather). Inoltre  possibile usare librerie standard scritte
  per computer paralleli. Occorre considerare sempre, per il rapporto
  fra portabilit ed efficienza).



  Per ragioni storiche, la maggior parte dei sorgenti di programmi che
  effettuano pesanti calcoli ("number crunching") sono scritti in
  FORTRAN.  Per questo motivo, il FORTRAN ha il supporto maggiore
  (strumenti, librerie, ecc.) per l'elaborazione parallela. Molti
  programmatori, adesso, utilizzano il C o riscrivono in C vecchie
  applicazioni scritte in FORTRAN con l'idea che il C permetter
  un'esecuzione pi veloce.  Questo  vero, dal momento che il C 
  quanto di pi vicino ad un linguaggio macchina universale, ma ha anche
  alcuni svantaggi.  L'utilizzo di puntatori, in C, rende estremamente
  difficile determinare le dipendenze fra i dati. Se avete un programma
  FORTRAN e pensate di parallelizzarlo, NON CONVERTITELO IN C!



  44..55..33..22..  MMeettooddii IImmpplliicciittii


  Sono quelli in cui l'utente lascia alcune (o tutte) decisioni di
  parallelizzazione al compilatore. Esempi sono FORTRAN 90, High
  Performance FORTRAN (HPF), Bulk Synchronous Parallel (BSP) e un'intera
  collezione di altri metodi che sono sotto sviluppo.



  I metodi impliciti richiedono che l'utente fornisca alcune
  informazioni circa la natura concorrente dell'applicazione, ma il
  compilatore, poi, prender la decisione di come eseguire, questa
  concorrenza, in parallelo.  Questi metodi forniscono alcuni livelli di
  portabilit ed efficienza, ma non c' ancora alcun "modo perfetto" per
  descrivere un problema concorrente per un'elaborazione parallela.


  55..  RRiissoorrssee ppeerr BBeeoowwuullff



  55..11..  PPeerr ccoommiinncciiaarree



    La mailing list di Beowulf.  Per iscriversi mandare un messaggio a
     beowulf-request@cesdis.gsfc.nasa.gov con la parola _s_u_b_s_c_r_i_b_e nel
     corpo del messaggio.

    La homepage di Beowulf http://www.beowulf.org

    Extreme Linux http://www.extremelinux.org

    Extreme Linux Software di Red Hat http://www.redhat.com/extreme



  55..22..  DDooccuummeennttaazziioonnee



    L'ultima versione del Beowulf HOWTO
     http://www.sci.usq.edu.au/staff/jacek/beowulf.

    Costruire un sistema Beowulf
     http://www.cacr.caltech.edu/beowulf/tutorial/building.html

    I link di Jacek su Beowulf
     http://www.sci.usq.edu.au/staff/jacek/beowulf.

    Beowulf Installation and Administration HOWTO (DRAFT)
     http://www.sci.usq.edu.au/staff/jacek/beowulf.

    Linux Parallel Processing HOWTO
     http://yara.ecn.purdue.edu/~pplinux/PPHOWTO/pphowto.html



  55..33..  DDooccuummeennttii ccaarrttaacceeii



    Chance Reschke, Thomas Sterling, Daniel Ridge, Daniel Savarese,
     Donald Becker, and Phillip Merkey _A _D_e_s_i_g_n _S_t_u_d_y _o_f _A_l_t_e_r_n_a_t_i_v_e
     _N_e_t_w_o_r_k _T_o_p_o_l_o_g_i_e_s _f_o_r _t_h_e _B_e_o_w_u_l_f _P_a_r_a_l_l_e_l _W_o_r_k_s_t_a_t_i_o_n.
     Proceedings Fifth IEEE International Symposium on High Performance
     Distributed Computing, 1996.
     http://www.beowulf.org/papers/HPDC96/hpdc96.html


    Daniel Ridge, Donald Becker, Phillip Merkey, Thomas Sterling
     Becker, and Phillip Merkey. _H_a_r_n_e_s_s_i_n_g _t_h_e _P_o_w_e_r _o_f _P_a_r_a_l_l_e_l_i_s_m _i_n
     _a _P_i_l_e_-_o_f_-_P_C_s.  Proceedings, IEEE Aerospace, 1997.
     http://www.beowulf.org/papers/AA97/aa97.ps


    Thomas Sterling, Donald J. Becker, Daniel Savarese, Michael R.
     Berry, and Chance Res. _A_c_h_i_e_v_i_n_g _a _B_a_l_a_n_c_e_d _L_o_w_-_C_o_s_t _A_r_c_h_i_t_e_c_t_u_r_e
     _f_o_r _M_a_s_s _S_t_o_r_a_g_e _M_a_n_a_g_e_m_e_n_t _t_h_r_o_u_g_h _M_u_l_t_i_p_l_e _F_a_s_t _E_t_h_e_r_n_e_t _C_h_a_n_n_e_l_s
     _o_n _t_h_e _B_e_o_w_u_l_f _P_a_r_a_l_l_e_l _W_o_r_k_s_t_a_t_i_o_n.  Proceedings, International
     Parallel Processing Symposium, 1996.
     http://www.beowulf.org/papers/IPPS96/ipps96.html


    Donald J. Becker, Thomas Sterling, Daniel Savarese, Bruce Fryxell,
     Kevin Olson. _C_o_m_m_u_n_i_c_a_t_i_o_n _O_v_e_r_h_e_a_d _f_o_r _S_p_a_c_e _S_c_i_e_n_c_e _A_p_p_l_i_c_a_t_i_o_n_s
     _o_n _t_h_e _B_e_o_w_u_l_f _P_a_r_a_l_l_e_l _W_o_r_k_s_t_a_t_i_o_n.  Proceedings,High Performance
     and Distributed Computing, 1995.
     http://www.beowulf.org/papers/HPDC95/hpdc95.html



    Donald J. Becker, Thomas Sterling, Daniel Savarese, John E.
     Dorband, Udaya A. Ranawak, Charles V.  Packer. _B_E_O_W_U_L_F_: _A _P_A_R_A_L_L_E_L
     _W_O_R_K_S_T_A_T_I_O_N _F_O_R _S_C_I_E_N_T_I_F_I_C _C_O_M_P_U_T_A_T_I_O_N.  Proceedings, International
     Conference on Parallel Processing, 95.
     http://www.beowulf.org/papers/ICPP95/icpp95.html

    Papers at the Beowulf site
     http://www.beowulf.org/papers/papers.html



  55..44..  SSooffttwwaarree


    PVM - Parallel Virtual Machine
     http://www.epm.ornl.gov/pvm/pvm_home.html



    LAM/MPI (Local Area Multicomputer / Message Passing Interface)
     http://www.mpi.nd.edu/lam

    BERT77 - FORTRAN conversion tool http://www.plogic.com/bert.html

    Beowulf software from Beowulf Project Page
     http://beowulf.gsfc.nasa.gov/software/software.html

    Jacek's Beowulf-utils ftp://ftp.sci.usq.edu.au/pub/jacek/beowulf-
     utils

    Beowulfatch - cluster monitoring tool
     http://www.sci.usq.edu.au/staff/jacek/Beowulfatch



  55..55..  MMaacccchhiinnee BBeeoowwuullff


    Avalon  composto da 140 processori Alpha, 36 GB di RAM ed 
     probabilmente la pi veloce macchina Beowulf, viaggiando a 47,7
     Gigaflop e si trova al 114 posto della lista dei 500 computer pi
     veloci. http://swift.lanl.gov/avalon/

    Megalon-A Massively PArallel CompuTer Resource (MPACTR)   composto
     da 14 nodi CPU Pentium Pro quadriprocessore 200 e da 14 GB di RAM.
     http://megalon.ca.sandia.gov/description.html

    theHIVE - Highly-parallel Integrated Virtual Environment  un altro
     veloce Supercomputer Beowulf.  theHIVE  composto da 64 nodi, 128
     CPU per un totale di 4 GB RAM. http://newton.gsfc.nasa.gov/thehive/

    Topcat  una macchina molto pi piccola e consiste di 16 CPU e da
     1,2 GB di RAM. http://www.sci.usq.edu.au/staff/jacek/topcat

    MAGI cluster - questo  un sito molto interessante con molti link
     interessanti. http://noel.feld.cvut.cz/magi/



  55..66..  AAllttrrii ssiittii iinntteerreessssaannttii



    SMP Linux http://www.linux.org.uk/SMP/title.html

    Paralogic - Buy a Beowulf http://www.plogic.com


  55..77..  SSttoorriiaa


    Leggende - Beowulf  http://legends.dm.net/beowulf/index.html

    Le avventure di Beowulf
     http://www.lnstar.com/literature/beowulf/beowulf.html
  66..  CCooddiiccee ssoorrggeennttee


  66..11..  ssuumm..cc


  /* Jacek Radajewski jacek@usq.edu.au */
  /* 21/08/1998 */

  #include <stdio.h>
  #include <math.h>

  int main (void) {

    double result = 0.0;
    double number = 0.0;
    char string[80];


    while (scanf("%s", string) != EOF) {

      number = atof(string);
      result = result + number;
    }

    printf("%lf\n", result);

    return 0;

  }



  66..22..  ssiiggmmaassqqrrtt..cc



  /* Jacek Radajewski jacek@usq.edu.au */
  /* 21/08/1998 */

  #include <stdio.h>
  #include <math.h>

  int main (int argc, char** argv) {

    long number1, number2, counter;
    double result;

    if (argc < 3) {
      printf ("usage : %s number1 number2\n",argv[0]);
      exit(1);
    } else {
      number1 = atol (argv[1]);
      number2 = atol (argv[2]);
      result = 0.0;
    }

    for (counter = number1; counter <= number2; counter++) {
      result = result + sqrt((double)counter);
    }

    printf("%lf\n", result);

    return 0;

  }



  66..33..  pprruunn..sshh



  #!/bin/bash
  # Jacek Radajewski jacek@usq.edu.au
  # 21/08/1998

  export SIGMASQRT=/home/staff/jacek/beowulf/HOWTO/example1/sigmasqrt

  # $OUTPUT must be a named pipe
  # mkfifo output

  export OUTPUT=/home/staff/jacek/beowulf/HOWTO/example1/output

  rsh scilab01 $SIGMASQRT         1  50000000 > $OUTPUT < /dev/null&
  rsh scilab02 $SIGMASQRT  50000001 100000000 > $OUTPUT < /dev/null&
  rsh scilab03 $SIGMASQRT 100000001 150000000 > $OUTPUT < /dev/null&
  rsh scilab04 $SIGMASQRT 150000001 200000000 > $OUTPUT < /dev/null&
  rsh scilab05 $SIGMASQRT 200000001 250000000 > $OUTPUT < /dev/null&
  rsh scilab06 $SIGMASQRT 250000001 300000000 > $OUTPUT < /dev/null&
  rsh scilab07 $SIGMASQRT 300000001 350000000 > $OUTPUT < /dev/null&
  rsh scilab08 $SIGMASQRT 350000001 400000000 > $OUTPUT < /dev/null&
  rsh scilab09 $SIGMASQRT 400000001 450000000 > $OUTPUT < /dev/null&
  rsh scilab10 $SIGMASQRT 450000001 500000000 > $OUTPUT < /dev/null&
  rsh scilab11 $SIGMASQRT 500000001 550000000 > $OUTPUT < /dev/null&
  rsh scilab12 $SIGMASQRT 550000001 600000000 > $OUTPUT < /dev/null&
  rsh scilab13 $SIGMASQRT 600000001 650000000 > $OUTPUT < /dev/null&
  rsh scilab14 $SIGMASQRT 650000001 700000000 > $OUTPUT < /dev/null&
  rsh scilab15 $SIGMASQRT 700000001 750000000 > $OUTPUT < /dev/null&
  rsh scilab16 $SIGMASQRT 750000001 800000000 > $OUTPUT < /dev/null&
  rsh scilab17 $SIGMASQRT 800000001 850000000 > $OUTPUT < /dev/null&
  rsh scilab18 $SIGMASQRT 850000001 900000000 > $OUTPUT < /dev/null&
  rsh scilab19 $SIGMASQRT 900000001 950000000 > $OUTPUT < /dev/null&
  rsh scilab20 $SIGMASQRT 950000001 1000000000 > $OUTPUT < /dev/null&



