Newsgroup: it.comp.os.amiga
Titolo: SUN chiude

 capito..)
Il vero problema è che oggi chi programma, soprattutto in ambiente
PC-Wintel, lo fa
senza ottimizzare. Aspettate tutti, non voglio riaprire una spinosa
questione sull'ottimizzazione fine a se stessa, che per altro io non
condivido.
Uso il termine nel senso più ampio del suo significato, secondo il quale
ottimizzare non vuol dire limare cicli macchina manipolando direttamente il
codice assembly, ma scegliere quale sia, ogni volta, la soluzione migliore
al nostro problema. E per far ciò bisogna studiare a tavolino diversi
algoritmi per risolverlo, e poi provare sul campo ad implementare i
migliori e nel modo più efficace ed intelligente possibile, per poter
identificare quello che garantisce le prestazioni migliori. Ovviamente
tutto ciò ha un costo, ecco perchè sono in pochi a farlo!
Non ha alcun senso ottimizzare il codice macchina di un programma per
trovare i numeri primi da 1 fino a 1.000.000.000 utilizzante solo la forza
bruta, perché con un algortimo più inteligente si otterrà il risultato più
velocemente anche se il programma è scritto in un linguaggio interpretato
come
Rebol o Python, ma in questo caso, oltre tutto, si è liberi di scegliere la
piattaforma sul
quale far girare il programma senza alcuna modifica. In quest'ottica Java è
il prodotto vincente vista portabilità, pre-compilazione, e ottimizzazione
al volo che oggi garantiscono prestazioni non troppo diverse da quelle del
C/C++ sulle attuali macchine commercialmente valide, sempre che il
programmatore sappia quello che fa ;)
Molto spesso si privilegia un algoritmo CPU Intensive piuttosto che Memory
Intensive, ma può essere un errore per l'evoluzione futura, infatti il
costo delle memorie, in generale, scende molto più rapidamente di quello
delle CPU. E l'uso delle tabelle pre-calcolate accelera notevolmente i
calcoli.
Su Wintel, spesso si inscatola tutto in wrapper, che poi verranno
inscatolati da altri in altri wrapper, e così via... Alla fine il programma
richiede un mare di memoria, ma usata in modo non efficiente, ed il
processore perde più tempo a passare i
dati da uno strato all'atro piuttosto che a macinare calcoli. Se si
aggiunge poi che molti preferiscono implementare il primo algoritmo che gli
viene in mente e nel modo più veloce possibile, cioè senza fermarsi a
riflettere sulle conseguenze, ci si rende subito conto del perché siano
lenti anche i programmi scritti in C. Poi c'è la tendenza a confidare ne
fatto che tra 6 mesi il processore sarà ancora più potente.... e la gente
ha memoria corta :)
Poi c'è anche l'impatto psicologico dei requisiti hardware spropositati,
soprattutto in ambito DTV, dove il programma che richiede maggiore memoria e
maggiore potenza di calcolo è ritenuto il prodotto più avanzato e
potente :(
Ciao
P.S. X Michele: se fai qualcosa per le fiere di Bari, fai un e-fischio che
organizziamo una rimpatriata con l'AGI Puglia ;) 
-- 
 "No bug, no fun!"
--
Posted from 
mail.teseo.it
 [195.216.224.1]
via Mailgate.ORG Server - 
http://www.mailgate.org

 
Si, ma c'e' anche da dire che le CPU aumentano di velocita' molto piu'
rapidamente delle memorie, e quella che puo' sembrare la soluzione piu'
adeguata adesso (l'uso di tabelle precalcolate) puo' rivelarsi un collo
di bottiglia per le macchine future.
Una buona soluzione potrebbe essere quella di usare sia Ram che CPU in
maniera equilibrata; puo' sembrare di aver scoperto l'acqua calda, ma
visti certi programmi questa soluzione non sembra cosi' evidente.
-- 
Ciao!
Cristian Venturini

Cristian Venturini

 Unite for Java - Join the Java Lobby now! (
http://www.javalobby.org
)     <
============================================================================