Luca Fini <lfini_at_arcetri.astro.it> wrote in message
Pine.LNX.4.10.9911241148170.5123-100000_at_lfini.arcetri.astro.it...
>
> On 22 Nov 1999, Giampaolo Tomassoni wrote:
>
> > Luca Polo <Luca.Polo_at_gest.unipd.it.REMOVE-THIS> wrote in message
> > x71z9p2o5q.fsf_at_gest.unipd.it...
>
> > > Hanno campi di applicazione diversi: ciascuno nel suo e' "il
> > > migliore";
> > > usare il C++ per calcolo numerico e il FORTRAN per le interfacce
> > > grafiche e` un assurdo.
> >
> > Non so quale cervellone te lo abbia detto, ma non sono non � vero: �
pure
> > sbagliato.
>
> Le affermazioni apodittiche come quella di G.T. sono spesso piu'
> sbagliate di quelle che confutano.
Guarda che il perch� l'ho spiegato di seguito...
> > I 'domini applicativi' di FORTRAN, C e C++ (ma persino del Basic...)
> > sono perfettamente sovrapponibili. Prova ne � che esistono librerie
> > di analisi d'immagini o ricerca operativa in ognuno di questi
> > linguaggi.
>
> In linea di massima i campi applicativi di TUTTI i linguaggi di
> programmazione sono perfettamente sovrapponibili; nel senso che alla fine
> un qualunque problema puo' essere risolto, piu' o meno, con qualunque
> linguaggio di programmazione. Se pero' vai nel dettaglio, allora le
> differenze ci sono.
Scusa, ma non stiamo parlando del dettaglio?
Guarda che il dominio applicativo di un linguaggio non � l'insieme delle
funzioni che possono essere realizzate con esso. Anzi, non � strettamente un
oggetto matematico. � pi� simile ad un concetto, dato che la sua estensione
viene delimitata dagli obiettivi che si sono prefissi gli ideatori del
linguaggio.
Prendiamo l'RPG II od il Cobol. � ovvio che puoi realizzarci una FFT, ma si
tratta sempre di linguaggi molto pi� portati alla descrizione e gestione di
maschere video, stampe ed archivi che non al calcolo, perch� i loro ideatori
intendevano realizzare un linguaggio per uso gestionale, dove � molto pi�
utile avere buoni strumenti per la formattazione delle schermate o delle
stampe, che non poter fare operazioni matematiche complesse.
Il C ed il C++, invece, NASCONO come linguaggi orientati al calcolo
numerico.
Prova ne � (mi ripeto) che le pi� efficienti librerie matematiche per
Fortran sono realizzate in C...
Infatti, il C ed il C++ sono fondamentalmente concepiti come valutatori di
espressioni dove, rispetto all'aritmetica di base, sono stati aggiunti gli
operatori ',' e ';' come separatori, '{' e '}' come raggruppatori. In
definitiva, un sorgente C viene visto dal compilatore come una singola
espressione. Quello che in altri linguaggi viene chiamato 'istruzione' �, in
C, visto +o- come una funzione interna (vd. for(;;), while(), ecc) e sono
pochissime. Insomma, sono linguaggi che nascono con il concetto di
espressione quale essenza. La forza del C � che, ottimizzando le
espressioni, si ottimizza di fatto tutto il codice.
Senza contare che l'ANSI C e C++ supporta una serie di modificatori
('const', 'volatile' e 'static', ma anche '__inline' nelle sue estensioni)
che forniscono al compilatore una ricca serie di informazioni utili per
l'ottimizzazione, che il Fortran non pu� fornire.
Il compilatore C � certo, ad esempio, che una funzione static non pu� essere
chiamata dall'esterno del file sorgente in cui � definita, che un parametro
'const' non subisce modifica n� da parte della funzione in cui � definito,
n� dalle funzioni da essa chiamate, che un metodo const in una classe C++
non modifica alcun attributo della classe stessa...
Insomma, c'� un ricco campionario di strumenti che nascono con l'obiettivo
di permettere una pi� puntuale interpretazione della 'semantica' del codice
da parte del compilatore.
Il Fortran non arriva cos� lontano.
Il contesto della risposta che citi � che Polo descriveva il C++ come un
linguaggio "orientato alle interfacce grafiche". Sciocchezze che non hanno
alcun fondamento, dato che le varie librerie di moduli per la gestione
grafica sono costruite sopra al linguaggio e sono rappresentate da funzioni
e/o classi a cui dal codice si fa riferimento. Non fanno affatto parte del
linguaggio.
Semmai, il C ed il C++ sono linguaggi con dominio applicativo di pi� ampio
spettro, ma perch� K&R e successori hanno scelto di minimizzare le 'barriere
linguistiche' introdotte da questi linguaggi disegnandone l'ossatura sulla
valutazione di espressioni e demandando il resto a funzioni esterne.
Cambiando (o aggiungendo) librerie di funzioni e classi, si pu� stravolgere
(od estendere) il dominio applicativo del linguaggio. Solo la struttura
basata
sulle espressioni resta.
Il Fortran non fa un uso altrettanto esteso del concetto di espressione: c'�
lo statement e c'� l'espressione, e queste sono due cose diverse.
> > Semmai, per quanto riguarda l'efficienza, il FORTRAN � senz'altro il
> > peggiore tra i linguaggi che ho indicato, con il C (seguito da C++) al
> > top in fatto di performances: molte delle pi� efficienti librerie di
> > analisi d'immagine si basano su routine scritte in C, che vengono rese
> > utilizzabili anche da FORTRAN.
>
> Qui mi sembra che si confondano le cose: una cosa e' il linguaggio,
> un'altra una particolare implementazione di compilatore. Quindi ci possono
> essere compilatori C che producono in media codice piu' efficiente di
> compilatori Fortran,
Vabb�, esasperando questo concetto vorresti suggerire di comparare programmi
scritti in Fortran su Cray con quelli scritti in C su i486?
� ovvio che stavo parlando di compilatori tra loro paragonabili, su
piattaforme tra loro paragonabili. Tipo, che so, il top con il top.
� a mio avviso un fatto che il Fortran si presti meno del C
all'ottimizzazione. Se poi c'� qualche produttore che, pur di vendere i
propri prodotti, � disposta ad investire pesantemente sulla realizzazione di
un compilatore Fortran altamente ottimizzato, questo � un altro paio di
maniche. Ma quanto costa una copia di quel compilatore?
> ma qui si discute di una caratteristica generale
> dipendente dalla struttura del linguaggio.
� proprio la struttura del linguaggio che rende il Fortran difficilmente
ottimizzabile. Non solo, mostra palesemente che si tratta di un linguaggio
di vecchia generazione sul quale (mi ripeto di nuovo) non ha senso investire
pi� di tanto perch� la ricerca di nuove metodologie di ottimizzazione �
morta.
> > I motivi che sono fonte delle basse performances del FORTRAN sono da
> > ricercare nella pesante gestione dei 'Passing Parameters', nell'uso di
> > costrutti un po' troppo lontani dalla macchina per quanto concerne il
> > 'File Handling' nonch�, soprattutto, nell'assenza del tipo di dato
> > 'Pointer to' e nella pervicacia con cui il FORTRAN si ostina a verifi-
> > care che gli indici di array siano entro i limiti dell'array stesso.
>
> Il FORTRAN ha tradizionalmente un unico modo di passaggio dei parametri
> che si presta ad implementazioni assai efficienti (ovvero corrisponde ad
> istruzioni "native" di gran parte delle CPU), e non e' diversa dalla
> implementazione del passaggio di puntatori che si puo' avere in C.
A si? Prova a passare un sottoarray e vedrai. Un sacco di sorgenti Fortran
abusano di questo tipo d'operazione, con il risultato che il compilatore �
costretto a generare codice per accedere correttamente gli elementi
dell'array. In pi�, nei pp di una funzione non puoi specificare quali siano
quelli costanti (cio� non modificati dalla funzione o da una sua
sottofunzione) e quali quelli 'volatili', con il risultato che il
compilatore non pu� fare assunzioni sulla destinazione d'uso di un parametro
quando, ad esempio, questo venga utilizzato in una funzione per chiamare
un'altro funzione che non � definita all'interno dello stesso sorgente.
> E' Falso che il linguaggio fortran forzi la verifica degli indici degli
> array. Anzi e' vero il contrario: la maggior parte dei compilatori ha una
> opzione per avere la verifica che normalmente non viene implementata.
Mah. Mi pare che quelli che ho usato io la implementavano, ma pu� darsi che
in questo tu abbia ragione. Ma sull'assenza di puntatori che mi dici? Eppure
sono utilissimi per implementare, ad esempio, delle liste, che il fortran
pu� solo 'emulare' con degli array.
Senza contare che manca completamente il concetto di struttura (o di classe,
facendo il paragone con il C++), che sono elementi in grado di rendere
eccezionalmente efficiente l'accesso ai dati. Anche in questo caso il
fortran pu� solo emulare questa tipologia di dati attraverso l'ingombrante
uso di array, mandando come minimo a pallino il data caching dei processori
pi� efficienti.
>
> > Come se non bastasse, la grammatica del FORTRAN � non-Regolare, tipica
> > dei linguaggi di vecchia generazione come, ad esempio, il COBOL. La
> > ricerca in questo settore � stata completamente abbandonata, dato che
> > questo tipo di grammatica risulta in compilatori molto complessi e
> > nell'impossibilit� di adottare metodi di ottimizzazione che la ricerca
> > stessa ha reso molto efficaci (ed una delle risorse di C e C++).
>
> Non credo che la grammatica del linguaggio abbai una grande influenza
> sull'ottimizzazione, ma e' comunque vero che la ricerca sui compilatori
> FORTRAN e' assai limitata a causa del maggiore successo degli altri
> linguaggi.
La grammatica di un linguaggio � FONDAMENTALE per l'ottimizzazione.
L'ottimizzazione non � solo un'operazione che si compie sul codice oggetto
generato. Magari fosse cos� semplice. Devi conoscere i tipi di dati
coinvolti ed il loro 'scope', lo scope delle varie porzioni di codice,
stabilire limiti ad eventuali ottimizzazioni di tipo globale, identificare
loop, ecc, ecc, ecc.
Il Fortran ha una struttura che non permette una grande ottimizzazione
contestuale. Per farlo, un compilatore dovrebbe leggersi tutti i sorgenti
che concorrono alla costruzione di un programma (compresi quelli delle
librerie) ed a quel punto fare illazioni sugli scope delle variabili e delle
funzioni. Un compilatore del genere sarebbe molto complesso (e, quindi, pi�
incline a sbagliare) ed anche di scarsa utilit�, dato che raramente si
dispone dei sorgenti delle librerie che si usano.
Ciao,
--
------------------------------------------------------
Giampaolo Tomassoni Information Systems Consultant
P.za 8 Aprile 1948, 4 Tel/Fax: +39 (578) 21100
I-53044 Chiusi (SI) e-mail: tomassoni_at_geocities.com
ITALY
homepage: http://www.geocities.com/Eureka/Park/2209/
Received on Sun Nov 28 1999 - 00:00:00 CET