Dedicato a z
Caro z,
mi dispiace che il mio ritardo a rispondere ti abbia indotto a pensare che "mi hai lasciato dei bla"... e siccome oggi vengo fresco fresco da una giornata in cui uno dei miei "periodi stressati" è terminato, mi sono preso un paio d'ore di relax... ed eccomi qua. Riguardo i tuoi commenti:
per quello che riguarda le presentazioni e LaTeX dobbiamo ammettere una cosa (detta da un estremista del LaTeX, premetto): LaTeX non è lo strumento ideale per fare delle presentazioni in quanto, quando ci si accinge a prepararne una, si deve in qualche modo contraddire la filosofia stessa del LaTeX. Mi spiego meglio: quello che rende LaTeX straordinario è la filosofia secondo la quale il redattore e l'editore del documento non devono essere la stessa persona. Chi sa di matematica, e vuole trasmettere su carta il suo sapere, non è necessariamente un esperto in tipografia. Con LaTeX si deve, in generale, sottostare a delle regole tipografiche che qualcun altro, esperto in materia, ha scritto. L'utente può effettuare dei cambiamenti relativi alle impostazioni tipografiche solo a prezzo di qualche sacrificio, che in generale costa tanto quanto impratichirsi nell'arte tipografica (su questo ci sarebbe ancora da parlare, ma mi fermo qui). Ecco perché i documenti LaTeX sono molto più belli di quelli Word: oltre ai fonts, che sono oggettivamente belli, ma potrebbero in linea di principio essere importati in Word, l'utente non può decidere dove posizionare il titolo, con che grandezza etc. Questa filosofia non è rispettata nel caso delle slides, per le quali, le due persone del redattore e dell'impaginatore devono coincidere perché l'impostazione grafica è parte dell'informazione che si vuole trasmettere: dove posizionare una figura (esattamente lì dove la si vuole) è di primaria importanza nella presentazione, ed enfatizzare un concetto con un font piuttosto che un altro fa parte del contenuto. In questi casi, quindi, accedere alle impostazioni LaTeX "fini" può essere scomodo.
Detto questo, appunto, io uso LaTeX anche per le presentazioni (anche per la lista della spesa, direi, quindi non faccio testo): non solo sono, a mio avviso, belle, ma ritengo che anche nel caso delle slides, abbandonarsi alla filosofia LaTeX, autolimitandosi nelle libertà su fonts, colori, è un bene: alcune presentazioni che si vedono in giro sono talmente colorate e scoppiettanti da far passare il contenuto in secondo piano. Il primo pacchetto dedicato alle slides, in ordine ti tempo, credo sia stato proprio prosper: l'ho usato; non solo ha molte scomodità e incompatibilità, ma se gli stili forniti non sono soddisfacenti, è difficile crearne uno proprio. Poi venne beamer (almeno nell'ordine in cui io li ho usati): questo pacchetto rimane il più ricco di funzionalità ed è quello che raccomando sempre. Ci sono molte possibilità di personalizzare il documento, e ambienti dedicati. Tra gli svantaggi, quello della compilazione obbligatoria in pdfLaTeX. La cosa migliore di beamer, comunque, è il manuale. Prima di essere un guida su com usare beamer, è una guida su come fare delle presentazioni in generale, e ripristina la filosofia LaTeX anche nelle slides: se puoi leggila, è interessantissima. Recentemente, comunque, è nato un nuovo progetto, una costola del vecchio prosper. Il pacchetto si chiama powerdot. Ha grossomodo le funzionalità di beamer (quasi tutte, devo dire, e ne anche di nuove), un manuale ridottissimo (quindici pagine) e crearsi il proprio stile è abbastanza facile. Io ormai uso stabilmente quest'ultimo, soprattutto perché le presentazioni beamer sono oramai viste e straviste: in alcune conferenze mi è capitato di vedere fino a tre presentazioni consecutive con lo stesso stile di beamer.
MPI: nel mio caso, una manna dal cielo. Cercando soluzioni di sistemi di equazioni con più di due milioni di incognite (un numero preciso, non una cifra sparata a caso per dire "grande"), ho la necessità di spargerle il più possibile nei vari processori, con tutto quello che questo comporta sia dal punto di vista algoritmico (non tutti gli algoritmi sono parallelizzabili con la stessa efficienza), sia dal punto di vista del codice stesso (una volta che uno sa cosa fare dal punto di vista concettuale, scrivere il codice relativo non è sempre facile). Tra le varie implementazioni MPI (tra cui OpenMPI, Lam MPI, Mpich), io utilizzo sia OpenMpi che Lam MPI: allo stato attuale ho un codice che è portabile (gira, anzi, sta girando anche in questo momento!) su Linux 32 e 64 bit, Sun, e, udite udite Mac OS (ci ritornerò dopo...). Ho un makefile che compila in modo differente a seconda dell'architettura, e chiama l'eseguibile con MPI di conseguenza. Il codice gira indifferentemente su 1,2,3,..., n processori. Come sicuramente saprai, non sempre ha senso aumentare il numero di processori a dismisura, perché non tutti gli algoritmi sono scalabili (leggi: girano m volte più veloce se aumenti il numero di processori di un fattore m).
Non ti avevo ancora detto che sono passato dal C al C++. E quando intendo C++, intendo vera programmazione ad oggetti: ho fatto una discreta fatica a passare a questo stile di programmazione, ma la cosa ha portato ha i suoi frutti. Nel mio caso avevo bisogno di utilizzare lo stesso codice per girare una moltidudine di modelli diversi, che ora sono tradotti un opportune classi. Utilizzo le librerie Trilinos per il calcolo computazionale (http://software.sandia.gov/trilinos/): i laboratori del SandiaLabs (che ho visitato personalmente lo scorso Ottobre) hanno riscritto i classici Blas, Lapack in chiave object oriented, complementandoli con una serie di pacchetti aggiuntivi spaventosi. Dai un'occhiata alla pagina web per vedere quanto il progetto sia esteso. Al Sandia Labs utilizzano queste librerie per scrivere codici che girano su supercalcolatori con centinaia di migliaia di nodi (ancora una volta questa è una stima adeguata, non è un numero grande a caso). Quando ero lì, mi hanno "prestato" un clusterino da 64 processori: "Tanto non lo usa nessuno" è stata la motivazione ufficiale. Usare queste librerie non significa avere degli oggetti "black box" a disposizione, ma bisogna programmare nel dettaglio. Lunghezza media di uno dei miei codici: 2000-3000 linee di comando, senza prendere in considerazione le classi "atomistiche" che uso di default che fanno 7000-8000 linee. Insomma, un po' stressante stargli dietro (e forse capirai perché ho lasciato un po' andare il blog...), ma molto remunerativo: i codici sono veramente molto, molto efficienti. Siamo alle solite: vuoi qualcosa che funzioni veramente bene? Allora devi soffrire con una curva d'apprendimento vertiginosa. Per me è stato sempre così: a cominciare da come digitare sulla tastiera (ricordo di un gioco formidabile sotto linux per imparare a digitare correttamente con tutte le dita), per continuare con Vim (ed il mouse, chi lo usa più) passando per LaTeX e così via...
Ed ora la mela: ultimo acquisto del mio supervisore (espressamente per me ed un mio collega, devo dire) è un server Mac, due Dual Core (Intel) e 8 GB di Ram. Mangio mela, quindi, anche se mi perdo la parte più succosa, cioè la possibilità di avere tutte le funzionalità desktop... ma prima o poi...
Ovviamente, su questa macchina sono "quasi" root, perché ho dovuto installare da zero tutti i pacchetti (OpenMPI, Trilinos, etc.) ed indovina un po' dove ho preso tutte le dritte? Proprio sul sito di High Performance Computing per Mac che mi hai segnalato tu... ed ora alcune considerazioni conclusive:
1) A parte questo lato smanettone, mi occupo anche di Matematica. Matematica applicata, va bene, ma pur sempre Matematica. E di questo mi piacerebbe parlarti(vi?) prossimamente, perché ci sono un mucchio di novità al riguardo.
2) Più mi scrivi e più mi rendo conto che ci interessiamo di molte cose in comune. Quando andrò a trovare Paolo e magari Davide, a Firenze, che ne diresti di unirti a noi per una birra?
3) Non so se sono stato chiaro: grazie dei tuoi "bla"!
4) Qualche dritta sulle flag da usare con g++ con Intel Mac? Tra tutte le macchine che uso, il server Mac è quella più nuova, ma ancora, ahimé la più lenta.
Un abbraccio
Daniele
mi dispiace che il mio ritardo a rispondere ti abbia indotto a pensare che "mi hai lasciato dei bla"... e siccome oggi vengo fresco fresco da una giornata in cui uno dei miei "periodi stressati" è terminato, mi sono preso un paio d'ore di relax... ed eccomi qua. Riguardo i tuoi commenti:
per quello che riguarda le presentazioni e LaTeX dobbiamo ammettere una cosa (detta da un estremista del LaTeX, premetto): LaTeX non è lo strumento ideale per fare delle presentazioni in quanto, quando ci si accinge a prepararne una, si deve in qualche modo contraddire la filosofia stessa del LaTeX. Mi spiego meglio: quello che rende LaTeX straordinario è la filosofia secondo la quale il redattore e l'editore del documento non devono essere la stessa persona. Chi sa di matematica, e vuole trasmettere su carta il suo sapere, non è necessariamente un esperto in tipografia. Con LaTeX si deve, in generale, sottostare a delle regole tipografiche che qualcun altro, esperto in materia, ha scritto. L'utente può effettuare dei cambiamenti relativi alle impostazioni tipografiche solo a prezzo di qualche sacrificio, che in generale costa tanto quanto impratichirsi nell'arte tipografica (su questo ci sarebbe ancora da parlare, ma mi fermo qui). Ecco perché i documenti LaTeX sono molto più belli di quelli Word: oltre ai fonts, che sono oggettivamente belli, ma potrebbero in linea di principio essere importati in Word, l'utente non può decidere dove posizionare il titolo, con che grandezza etc. Questa filosofia non è rispettata nel caso delle slides, per le quali, le due persone del redattore e dell'impaginatore devono coincidere perché l'impostazione grafica è parte dell'informazione che si vuole trasmettere: dove posizionare una figura (esattamente lì dove la si vuole) è di primaria importanza nella presentazione, ed enfatizzare un concetto con un font piuttosto che un altro fa parte del contenuto. In questi casi, quindi, accedere alle impostazioni LaTeX "fini" può essere scomodo.
Detto questo, appunto, io uso LaTeX anche per le presentazioni (anche per la lista della spesa, direi, quindi non faccio testo): non solo sono, a mio avviso, belle, ma ritengo che anche nel caso delle slides, abbandonarsi alla filosofia LaTeX, autolimitandosi nelle libertà su fonts, colori, è un bene: alcune presentazioni che si vedono in giro sono talmente colorate e scoppiettanti da far passare il contenuto in secondo piano. Il primo pacchetto dedicato alle slides, in ordine ti tempo, credo sia stato proprio prosper: l'ho usato; non solo ha molte scomodità e incompatibilità, ma se gli stili forniti non sono soddisfacenti, è difficile crearne uno proprio. Poi venne beamer (almeno nell'ordine in cui io li ho usati): questo pacchetto rimane il più ricco di funzionalità ed è quello che raccomando sempre. Ci sono molte possibilità di personalizzare il documento, e ambienti dedicati. Tra gli svantaggi, quello della compilazione obbligatoria in pdfLaTeX. La cosa migliore di beamer, comunque, è il manuale. Prima di essere un guida su com usare beamer, è una guida su come fare delle presentazioni in generale, e ripristina la filosofia LaTeX anche nelle slides: se puoi leggila, è interessantissima. Recentemente, comunque, è nato un nuovo progetto, una costola del vecchio prosper. Il pacchetto si chiama powerdot. Ha grossomodo le funzionalità di beamer (quasi tutte, devo dire, e ne anche di nuove), un manuale ridottissimo (quindici pagine) e crearsi il proprio stile è abbastanza facile. Io ormai uso stabilmente quest'ultimo, soprattutto perché le presentazioni beamer sono oramai viste e straviste: in alcune conferenze mi è capitato di vedere fino a tre presentazioni consecutive con lo stesso stile di beamer.
MPI: nel mio caso, una manna dal cielo. Cercando soluzioni di sistemi di equazioni con più di due milioni di incognite (un numero preciso, non una cifra sparata a caso per dire "grande"), ho la necessità di spargerle il più possibile nei vari processori, con tutto quello che questo comporta sia dal punto di vista algoritmico (non tutti gli algoritmi sono parallelizzabili con la stessa efficienza), sia dal punto di vista del codice stesso (una volta che uno sa cosa fare dal punto di vista concettuale, scrivere il codice relativo non è sempre facile). Tra le varie implementazioni MPI (tra cui OpenMPI, Lam MPI, Mpich), io utilizzo sia OpenMpi che Lam MPI: allo stato attuale ho un codice che è portabile (gira, anzi, sta girando anche in questo momento!) su Linux 32 e 64 bit, Sun, e, udite udite Mac OS (ci ritornerò dopo...). Ho un makefile che compila in modo differente a seconda dell'architettura, e chiama l'eseguibile con MPI di conseguenza. Il codice gira indifferentemente su 1,2,3,..., n processori. Come sicuramente saprai, non sempre ha senso aumentare il numero di processori a dismisura, perché non tutti gli algoritmi sono scalabili (leggi: girano m volte più veloce se aumenti il numero di processori di un fattore m).
Non ti avevo ancora detto che sono passato dal C al C++. E quando intendo C++, intendo vera programmazione ad oggetti: ho fatto una discreta fatica a passare a questo stile di programmazione, ma la cosa ha portato ha i suoi frutti. Nel mio caso avevo bisogno di utilizzare lo stesso codice per girare una moltidudine di modelli diversi, che ora sono tradotti un opportune classi. Utilizzo le librerie Trilinos per il calcolo computazionale (http://software.sandia.gov/trilinos/): i laboratori del SandiaLabs (che ho visitato personalmente lo scorso Ottobre) hanno riscritto i classici Blas, Lapack in chiave object oriented, complementandoli con una serie di pacchetti aggiuntivi spaventosi. Dai un'occhiata alla pagina web per vedere quanto il progetto sia esteso. Al Sandia Labs utilizzano queste librerie per scrivere codici che girano su supercalcolatori con centinaia di migliaia di nodi (ancora una volta questa è una stima adeguata, non è un numero grande a caso). Quando ero lì, mi hanno "prestato" un clusterino da 64 processori: "Tanto non lo usa nessuno" è stata la motivazione ufficiale. Usare queste librerie non significa avere degli oggetti "black box" a disposizione, ma bisogna programmare nel dettaglio. Lunghezza media di uno dei miei codici: 2000-3000 linee di comando, senza prendere in considerazione le classi "atomistiche" che uso di default che fanno 7000-8000 linee. Insomma, un po' stressante stargli dietro (e forse capirai perché ho lasciato un po' andare il blog...), ma molto remunerativo: i codici sono veramente molto, molto efficienti. Siamo alle solite: vuoi qualcosa che funzioni veramente bene? Allora devi soffrire con una curva d'apprendimento vertiginosa. Per me è stato sempre così: a cominciare da come digitare sulla tastiera (ricordo di un gioco formidabile sotto linux per imparare a digitare correttamente con tutte le dita), per continuare con Vim (ed il mouse, chi lo usa più) passando per LaTeX e così via...
Ed ora la mela: ultimo acquisto del mio supervisore (espressamente per me ed un mio collega, devo dire) è un server Mac, due Dual Core (Intel) e 8 GB di Ram. Mangio mela, quindi, anche se mi perdo la parte più succosa, cioè la possibilità di avere tutte le funzionalità desktop... ma prima o poi...
Ovviamente, su questa macchina sono "quasi" root, perché ho dovuto installare da zero tutti i pacchetti (OpenMPI, Trilinos, etc.) ed indovina un po' dove ho preso tutte le dritte? Proprio sul sito di High Performance Computing per Mac che mi hai segnalato tu... ed ora alcune considerazioni conclusive:
1) A parte questo lato smanettone, mi occupo anche di Matematica. Matematica applicata, va bene, ma pur sempre Matematica. E di questo mi piacerebbe parlarti(vi?) prossimamente, perché ci sono un mucchio di novità al riguardo.
2) Più mi scrivi e più mi rendo conto che ci interessiamo di molte cose in comune. Quando andrò a trovare Paolo e magari Davide, a Firenze, che ne diresti di unirti a noi per una birra?
3) Non so se sono stato chiaro: grazie dei tuoi "bla"!
4) Qualche dritta sulle flag da usare con g++ con Intel Mac? Tra tutte le macchine che uso, il server Mac è quella più nuova, ma ancora, ahimé la più lenta.
Un abbraccio
Daniele
posted by Daniele Avitabile at
8:41 PM
1 Comments:
Caro blogger,
non ti dico l'imbarazzo quando ho controllato il tuo blog per controllare se avevi avuto tempo di leggere: mi sono sentito, sinceramente, troppo in evidenza per tanta 'visibilità'. Così, un po' per la mancanza di tempo ed un po' per la vergogna eccomi ad aggiungere in ritardo altri bla sul tuo blog. In effetti hai miei occhi, rileggendo il post, le mie parole mi appaiono sempre più dei discorsi farfugliati usati a volte per ricordare o per parlare di cose che attualmente ho solo il tempo di sfiorare.
Il latex ultimamente lo utilizzo solo per aggiornare il mio cv o poco più, comunque fidandomi dei tuoi consigli mi sono scaricato powerdot al quale darò un'occhiata appena potrò. Ma cosa stai modellando con 2000000 di variabili ed a quale livello di dettaglio? Spero che i sistemi siano almeno fortemente sparsi; per le simulazioni, soprattutto quando le dimensioni sono così grandi mi chiedo cosa accada per quanto riguarda la stabilità numerica. Per adesso, spinto dalla curiosità, mi sono preso anche trilinos anche se non è chiaro quando e cosa ci farò? Intanto ho visto che per compilarlo che devo arricchire i miei compilatori con un fortran e dato che ci sono aggiornerò il gcc & C.: per adesso ho scaricato una snapshot di gcc43 (dal solito sito hpc.sf.net). Sugli switch di compilanzione sembra non vi sia niente di sicuro e forse vale la pena di seguire al discussione http://gcc.gnu.org/ml/gcc-help/2006-09/msg00139.html dove vengono suggerite alcune scelte possibili per 32bit e 64bit per il 4.2, il 4.3 dovrebbe avere un apposito -march=merom che non ho ancora provato.
Le differenze di velocità che ha misurato mi fanno pensare a quanto avevo letto riguardo sulla comparazione delle performance di 'number-crunching' su una macchina apple fra i s.o. osx e linux (http://sekhon.berkley.edu/macosx/intel.html) ripreso anche da (http://ridiculousfish.com/blog/archives/2006/05/16/36), magari ciò che viene detto è un po' datato ma il senso della cosa è che il problema la differenza di prestazioni potrebbe dovuto per alcune inefficienze di osx (rispetto a linux ed, incredibilmente, a windows!|)...non rimarrebbe che aspettare Leopard oppure usare il tuo server con il s.o. linux!
Comunque tornando al discorso sui compilatori: ho un caro amico che lavora nel fumoso settore della 'bioinformatica' che tempo fa mi raccontava che in quel di Dublino (alla ucd) hanno dato in pasto del software a degli specialisti di cluster e software parallelo della HewlettP. per realizzarne una versione più performante, mi sembra che fosse per l'analisi di alcune caratteristiche delle proteine a partire dalle cosidette 'mappe di contatto', ebbene, se non ricordo male, passando dal gcc al compilatore intel c++ [su s.o. linux] ottennero un aumento di circa il 25% senza effettuare alcuna ottimizzazione del codice; l'incremento raggiunse il 50% circa dopo la fase di ottimizzazione di alcune routine di base...Che dire, non ti rimane forse che provare il compilatore intel, ad esempio la versione trial e vedere cosa ottieni in casi reali.
In ultimo, quando vieni a Firenze sarò felice di incontrarsi e di conoscersi di persona anche se, ti avverto, sono praticamente un hobbista di "informatica" che cerca di dedicare un po' di tempo che rimane, tolto tutto il resto, alle sue curiosità, e che risulta essere, _almeno per ora_, così poco.
Un abbraccio a te e buona ricerca,
z
By
Anonimo, at 7:23 PM
Posta un commento
<< Home