--> "GP" == Giorgio Pastore <pastgio_at_univ.trieste.it> writes:
GP> Oggi le cose sono molto cambiate. La compattezza della traduzione LM non
GP> e' una misura dell' efficienza. Giusto per darti un esempio, compilatori
GP> efficienti sanno che trasformare la chiamata ad un sottoprogramma in
GP> codice 'in-line', anche se rende meno compatto l' eseguibile, e' un modo
GP> estremamente semplice di velocizzare l' esecuzione.
Perfetto. Fa piacere che c'e` ancora gente che "alza il cofano" per vedere
cosa fa andare la macchina, anche se non fa il meccanico.
GP> D' altra parte se ci fosse una dipendenza dell' efficienza del
GP> compilatore dalla complessita' del linguaggio, il fortran 90 non avrebbe
GP> nessuna speranza di raggiungere l' efficienza del f77.
E nessuno userebbe non dico il C++ (il cui obiettivo primario non e`
comunque la velocita` del codice), ma nemmeno il C ANSI: il vecchio C K&R
sarebbe ancora il preferito, non fosse altro che perche' consente di fare
certe porcherie con tipi e puntatori... :-)
>> si, ok, ma non puoi certo programmare in quickbasic solo perche' e'
>> banale leggere il sorgente.. eh! :-)
Quickbasic, banale da leggere ??? Sara` questione di formazione, ma se c'e`
un linguaggio per me illeggibile questo e` il BASIC (dopo il COBOL, ovvia-
mente :-)).
...
GP> Certo, pero' la mia esperienza con programmi che richiedevano centinaia
GP> di ore su supercomputers e' che i veri miglioramenti di efficienza
GP> (leggi: riduzione del tempo di CPU) vengono quasi sempre da modifiche
GP> negli algoritmi piu' che dai vari livelli di codifica.
Quello che ripeto anch'io almeno una volta al mese al tesista di turno (con
tesi nell'ambito della Ricerca Operativa) che ci chiede se non si puo`
espandere la RAM e/o avere una macchina piu` veloce perche' ottiene
messaggi di memoria esaurita, il programma deve girare per giorni, ecc.
I dialoghi sono piu` o meno cosi` (scusate la deriva, ma...):
T.: si puo` avere piu` memoria ?
Io: perche' ?
T.: sto facendo girare un programma e mi da` "memoria esaurita"...
Io: (so gia` come va a finire) che dimensione ha il problema ? Guarda che
gli algoritmi che usate voi di solito hanno complessita` cubica, come
minimo...
T.: ma e` solo un problema 10 x 20...
Io: ARGH!! (Nota: questo non vuol dire che sta lavorano con 10*20 = 200
elementi, ma -- stando al suo relatore -- con 10^20 elementi... segue
spiegazione in poche parole di dove sta sbagliando; ah, quando poi il
problema e` semplice, prendono l'approccio ricorsivo, che e` si` ele-
gante, ma esaurisce lo stack ed e` *molto* piu` lento...).
.... dopo qualche tempo ....
Io: (al relatore) ma quand'e` che smetterete di insegnare calcolo numerico
a degli ingegneri *gestionali* e non gli insegnate invece qualcosa sul-
la complessita` computazionale degli algoritmi, almeno nel campo della
R.O. ?
Ricominciate il dialogo da capo con un altro (o anche lo stesso) tesista,
con cadenza piu` o meno quindicinale...
Da notare che la macchina "lenta" e con "poca RAM" e` una Sun Ultra 60 con
CPU da 360 MHz, 512 MB di RAM (piu` 1 GB di swap) e dischi UW-SCSI... con
una macchina cosi`, ottimizzare il codice serve a poco: bisogna ragionare,
e non poco, sugli algoritmi (tanto piu` che la versione di "produzione"
deve poi girare in azienda e non certo su una macchina della stessa po-
tenza, ma su un normale PC, magari gia` datato...).
GP> Pero' so bene che tra i fisici il mito del programma "furbo" scritto in
GP> assembler e' duro a morire....
Sempre meglio del programma "furbo" scritto in Visual Basic... :-)
Saluti,
Luca Polo.
--
|~~~~~~~~~~~~~~~ Luca.Polo_at_gest.unipd.it (http://www.gest.unipd.it/~jake)
\_________________________________________________________________________
Associazione Astrofili del Basso Vicentino "Edmund Halley" - Sossano (VI)
http://www.gest.unipd.it/~jake/aabv o http://astrolink.mclink.it/ass/aabv
Received on Mon Nov 29 1999 - 00:00:00 CET