Newsgroup: it.comp.lang.c++
Titolo: L'altare della velocita'

Vorrei proporre un'argomento un po' diverso dai soliti strettamente tecnici.
Non so' quanto siate introdotti nell'ambiente della programmazione ma forse
avrete potuto notare quante cose vengono sacrificate per migliorare le
prestazioni di un'applicazione. 
E' impensabile vedere quanti professionisti anneghino in affermazioni
strampalate quando voglio raggiungere questo mito. Personalmente, su questo
argomento, ho sentito frasi del tipo "bisogna togliere i commenti...",
"CString occupa troppo spazio...", "usa sempre 'friend' che ti velocizza
l'accesso", "fai un thread per ogni funzione che risvegli quando ti serve"
ecc ecc. Il risultato spesso sono funzioni illeggibili (solitamente un vanto
per chi le ha prodotte), impossibli da modificare o debugare, e quasi mai si
raggiunge il risultato sperato. In verita' penso che sia impossibile
determinare -a priori- quali siano i punti in cui intervenire per migliorare
le prestazioni (salvo evidenti cicli da migliaia di operazioni). Tenuto
conto delle fondamentali regole di qualita' del software e delle
ottimizzazioni fatte dal compilatore (spesso legate alla CPU target), forse
sarebbe meglio produrre software piu' leggibile, piuttosto che cercare di
affinare funzioni che magari vengono chiamate solo una volta. Che ne
pensate?
Ciao
Merlino
--
Posted from 
igate.elsag.it
 [194.243.48.130]
via Mailgate.ORG Server - 
http://www.mailgate.org

Mi torna in mente la nota regola del 90-10
secondo cui il 90% del tempo richiesto da una applicazione,
viene speso nel 10% del suo codice.
In sostanza e` difficile dire a priori dove andare a mettere le mani,
un un buon profiler ed una serie di test sono essenziali.
L'alternativa e di andare a mettere le mani ovunque siamo in grado
di riconoscere un sia pur minimo overhead.
Tutti ad esempio sappiamo che il polimorfismo (le funzioni virtual)
hanno un costo, ma d'altronde anche la semplice chiamata di una
normale funzione ha un suo costo. Non per questo ha senso rinunciare
a priori alle funzioni (o a spargere inline a destra e a manca),
analogamente tutti sappiamo che srotolare un ciclo migliora
le prestazioni, ma bisogna sempre tener presente che si tratta
di miglioramenti locali che non necessariamente influiscono
a livello globale.
Tra l'altro gli aspetti da considerare in tali situazioni sono 
molteplici... Premesso che memoria e velocita` sono cose difficili da
conciliare (nel senso che spesso se vuoi + velocita` devi utilizzare
strutture dati + ricche o con funzioni inline avere un codice + grosso),
ad esempio ci si puo` porre problemi di localita` di codice e dati
(concetti fondamentali sui quali si basano le memorie cache)...
oppure in alcuni casi puo` interessare il tempo di servizio
(cioe` il tempo necessario perche` il programma accetti una
nuova richiesta) oppure il tempo di completamento (quello
necessario per esaurire uno stream di richieste).
In molti casi la soluzione non e` ottimizzare fino all'osso
quel 10% di codice (magari facendo riferimento all'architettura
sottostante) ma riuscire a parallelizzare la computazione nel
suo complesso (tipo il pipeline che viene utilizzato negli
applicativi di elaborazione di immagini).
Infine concludo con un esperimento fatto tempo fa con alcuni amici
circa l'efficienza di memset vs un cliclo for ottimizzato.
Il problema era nato dal lavoro di una delle persone coinvolte
(che si occupa di sistemi embedded), il dilemma era se utilizzare
una comoda e portabile memset oppure utilizzare un ciclo for
facendo riferimento all'architettura sottostante. Il problema non
e` banale, perche` raramente (almeno piu` di quanto possa sembrare) 
bisogna rinunciare alla portabilita` per avere maggiori prestazioni
(vedi sopra...).
Alla fine dai test fatti venne fuori che in generale il ciclo for e` 
assai piu` veloce, anche se alcuni compilatori implementano la
memset in modo tale che le prestazioni siano sostanzialmente
identiche.
Anche gli strumenti utilizzati hanno dunque un impatto non irrilevante.
Paolo
In sostanza se una persona mi dice a priori dove agire
(in modo preciso e dettagliato e non in linea di massima ndr.)
e` quanto meno sospetta.
-----------------------------------------------------------------
  Paolo Marotta
  Computer Science, University of Pisa
  home:   
http://www.cli.di.unipi.it/~marotta
-----------------------------------------------------------------

 pensate?
Penso che, almeno per quanto mi riguarda, sfondi una porta aperta. E da
quello che si legge sui "sacri" testi è proprio questo il giusto modo di
procedere. Chi si comporta come dici tu farebbe meglio ad utilizzare un
bel profiler.
EMG

bel profiler.
Il concetto di profiler mi e` un po' oscuro (diciamo che non lo ho mai
fatto).
Quali sono le tecniche e gli strumenti di profiling piu` utili e
potenti?
(Sotto Win e soprattutto Unix)
-- 
Gargamella alias Massimo Lauria
"Non e` bello cio` che e` bello, ma e` bello cio` che piace... a me!"

bel profiler.
Infatti, Carlo Pescio relega costoro nell'elenco degli stili di codifica
nel gradino piu` basso, nella categoria "Come sono furbo".
Il tipico prodotto del programmatore "artista", come li chiama lui.
-- 
Roberto Gerola
Email: 
robert...@penguinpowered.com
WWW: 
http://www.penguinpowered.com/~The_Cpp_Compass

Il tipico prodotto del programmatore "artista", come li chiama lui.
Per la serie "andiamo a mietere il grano!"  ;)
Paolo


E' sempre bello scoprire che c'e' ancora gente che si pone certi quesiti;
qualunque sviluppatore serio dovrebbe avere questi aspetti sempre
in testa.
La questione e' certamente spinosa, e molti degli strumenti di sviluppo
in giro attualmente, specie microsoft, sembrano fatti pensando a tutto
tranne che a quello.
E' meglio perdere tempo ad ottimizzare, o si fa prima ad aggiungere
qualche mega di memoria, o a passare alla prossima cpu piu' veloce?
Dovrei pensare piu' ad ottimizzare il mio codice, o a tenerlo piu'
portabile?
Penso che la cosa piu' sensata sia quella di analizzare di volta in volta
quali sono gli scopi delle tue applicazioni, e in quali ambienti si troveranno
a girare; non esiste una risposta assoluta. E' anche vero che nel mondo reale,
quasi mai (e c'e' un quasi di troppo) si ha il tempo di studiare le cose per bene,
cosi' come e' vero che se uno si mette a studiarci davvero rischia di perdersi
in ottimizzazioni infinite, alla ricerca della perfezione.
Quando va bene, e cioe' quando l'applicazione ha una vita abbastanza lunga,
allora si puo' procedere per passi successivi,ed arrivare ad un prodotto
decente.  D'altra parte, spesso ottimizzazioni che sembrano formidabili si rivelano 
come intoppi clamorosi non appena e' necessaria una modifica.
Io mi sono alternato per anni a scrivere programmi in ambienti proibitivi
come le schede programmabili con 256K di RAM e 64K di ROM ed in altri come windows, 
dove certi aspetti passano generalmente ed allegramente inosservati.
Se ti puo' consolare, io penso sempre che valga la pena di sforzarsi di fare il
meglio possibile, per quanto possibile; la qualita' dei tuoi programmi ne
trarra' sempre giovamento, per non parlare della soddisfazione personale.
E' innegabile pero' che quando si parla di applicazioni commerciali la
tendenza e' quella di preferire un upgrade del sistema con una spesa
irrisoria piuttosto che spendere decine di ore di sviluppo ed analisi.
Chi vivra' vedra'...


ICQ #34602650

 (Sotto Win e soprattutto Unix)
Non saprei. Il DJGPP offre il GPROF.EXE. Penso ci sia anche sotto Unix.
EMG

> argomento, ho sentito frasi del tipo "bisogna togliere i commenti...",
Io sono di questa opinione!
Se proprio devi ottimizzare qualcosa, i commenti sono quello che servono
meno, tanto poi devi comunque leggerti il codice e cambiarlo totalmente (a
meno di errori di programmazioni e/o ottimizzazioni banali tipo accedere una
matrice per righe invece che per colonne o cose simili).
Se non sono stato chiaro: quando ri-apri un sorgente per ottimizzarne le
prestazioni, devi leggerti prima i commenti, poi il codice ed infine
riscrivere il codice (e nuovi commenti).
Se invece i commenti non ci sono puoi sia evitarne la lettura, sia evitare
di scriverne di nuovi senza per questo sentirti in colpa.
Le prestazioni vanno tenute in conto mentre si scrive il codice, durante il
debug/testing del programma, (e quindi prima di scrivere i commenti), mentre
dopo, ai fini dell'ottimizzazione, servono al più per orientarti in mezzo al
sorgente.
Altro discorso per la manutenibilita': i commenti servono!! (e scrivere
codice leggibile di piu')
Comunque avrei un'opinione, adatta alla maggior parte delle applicazioni
reali (non in tempo reale): un programma scritto in C/C++ e' SEMPRE veloce,
se confrontato con lo stesso programma scritto in altri linguaggi.
Ovvio che se implemento un ciclo di 1 milione di iterazioni dove 100
bastavano...
Alessandro Monti

 matrice per righe invece che per colonne o cose simili).
Assumi per default che sei tu a scrivere il codice e tu a manutenerlo. 
PS: (domanda da ignorante) ma togliendo i commenti cosa si ottimizza? 


 PS: (domanda da ignorante) ma togliendo i commenti cosa si ottimizza? 
Per la verita` me lo sono chiesto anch'io.
 
Marco Guidi

 meno,
Peccato che i commenti non influiscano minimamente sull'efficienza del
programma in quanto non vengono nemmeno compilati e non fanno quindi
parte del codice finale.
EMG

A me e' capitato di lavorare in molte aziende importanti (sono un
consulente) e, purtroppo, ho notato che la qualita' del software non e'
quasi mai richiesta dal cliente, tutto quello che conta sono le prestazioni.
Potrei citare un paio di grossi progetti (costati anche miliardi) che sono
stati abbandonati perche' il codice era cosi' "esoterico" che neppure chi
l'ha scritto e' mai riuscito a farlo funzionare senza problemi.
Quando ho iniziato a lavorare avevo una grande stima degli sviluppatori
invece, col tempo, ho conosciuto molte persone che si riempivano la bocca di
termini tecnici senza conoscere veramente quello di cui parlavano (mi basta
pensare a quello che ha suggerito di togliere i commenti per aumentare la
velocita').
Certo so' bene quanto i tempi siano stretti per poter produrre qualcosa di
buono e, a volte, si puo' pensare che l'unica cosa importante e' che
l'applicazione funzioni. Nella programmazione ad oggetti, pero', un
ragionamento di questo tipo e' quanto mai inacettabile. Il codice che viene
scritto dovrebbe essere pensato per poter essere riutilizzato e scritto con
cura. Probabilmente qualche anno fa' nessuno pensava che il codice che
scriveva sarebbe durato a lungo, cosi' e' nato il bug dell'anno 2000.
Mi sembra comunque che le nuove generazioni di programmatori siano molto
piu' sensibili alla qualita' del software e che in un futuro il codice sara'
migliore.
Ciao
Emanuele Merlo


Un buon commento deve restare a livello di ntenzioni, cioè deve dire cosa le
righe a cui si riferisce fanno, non come lo fanno. L'ottimizzazione, ovvero il
cambiare quel "come", non influisce sul cosa. Se lo fa, probabilmente è il
commento ad essere troppo specifico. Ciò non vuol dire eliminare il commento, ma
scriverlo meglio.
Questo il linea di principio.
AB
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Andrea Baruzzo
Via Circonvallazione, 26
Muzzana del Turgnano (UD) - Italy
e-mail: 
andrea....@ud.nettuno.it
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Risposta per tutti quelli che mi spiegano che i commenti non vengono
compilati:
Ho scritto che è il programmatore che deve leggersi i commenti, non il
compilatore (che comunque deve saltarli e perciò qualche microsecondo lo
spreca).
Chiunque abbia scritto il programma, AI SOLI FINI DELL'OTTIMIZZAZIONE, e
quindi non per manutenzione, aggiornamenti, aggiunta di funzionalità e
altro, i commenti non servono a niente.
Ripeto, a meno di ottimizzazioni banali, per velocizzare davvero un
programma è necessario come minimo cambiare un algoritmo eseguito più spesso
dal programma.
Cambiare algoritmo = riscrivere tutto il codice.
Ne consegue che i commenti del tipo:
/*
    Questa funzione esegue un bubble-sort.
    Passo come parametri *vettore, di dimensione X,
    poi uso 2 variabili ciclo1 e ciclo2, scambio i dati tramite la funzione
swap() ecc. ecc.
*/
void bubble_sort (int *vettore){
int ciclo1, ciclo2;
for (ciclo1=0; ciclo1<100; ciclo1++)
    ...
}
Sono assolutamente inutili, perchè le uniche cose che mi servono sapere
sono:
- algoritmo usato (per usarne uno più efficiente)
- numero e tipo dei parametri
- tipo da ritornare
e le trovo nella riga di definizione della funzione.
Non accenniamo poi a cosa succede se invece di ottimizzare una piccola
procedura bisogna reingegnerizzare il programma!!!
Cosa ne facciamo dei commenti a funzioni o pezzi di codice che cancelleremo?
(e che sono deleteri perchè ci indicherebbero una strada già seguita e
fallimentare)
A meno che non si confondano i commenti con l'analisi e la documentazione
tecnica del programma...
Ammetto che la mia voleva essere una provocazione, e che in realtà uso
anch'io abbondanza di commenti, ma ritengo che questi siano utili SOLO per
debug fintantochè l'applicazione è in fase di sviluppo. A distanza di mesi
meglio leggersi l'analisi e semmai direttamente il codice.
--
Alessandro Monti
P.S.
Per chi crede che i commenti non influiscano sul tempo di esecuzione, posso
raccontare che a suo tempo ho realizzato un traslatore pascal-assembler, e
per ogni carattere di commento inserivo un ciclo di 100 NOP ;)

per ogni carattere di commento inserivo un ciclo di 100 NOP ;)
Bravo, questo si' che e' agire da professionisti.

per ogni carattere di commento inserivo un ciclo di 100 NOP ;)
Non so cosa sia un traslatore ma ribadisco che MAI i commenti influiscono
sul tempo di esecuzione di un programma compilato. La/le righe di commento
in fase di compilazione vengono proprio ignorate: non stanno
nell'eseguibile.
--
Francesco Trotta
http://space.tin.it/computer/ftrotta
Elimina "x_" dal mio indirizzo per mandarmi
un messaggio direttamente

 meglio leggersi l'analisi e semmai direttamente il codice.
Tu stesso hai detto che documentazione e commenti non vanno confusi.
Contengono informazioni diverse.
A distanza di mesi *bisogna* leggersi l'analisi della funzione se ci
vuoi mettere le mani, se non altro perchè può darsi che tu non l'abbia
mai letta (se la funzione non l'hai scritta tu...). Ma questo è un'altro
discorso.
I commenti hanno un'altro significato. 
Fra l'altro tu stesso hai detto poco più su che i commenti sono utili in
caso di manutenzione (e consideri i casi di aggiunta, modifica, etc...).
Quindi tu fai un'altra assunzione improbabile, che una volta finito lo
sviluppo non si fa più manutenzione.


per ogni carattere di commento inserivo un ciclo di 100 NOP ;)
Scusami ma non vedo il perche` di un tale comportamento... un commento
in pascal non ha alcun ruolo nell'eseguibile e quindi traslando il 
programma in assembler non c'e` motivo di aggiungere cicli vari...
Un commento puo` far perdere tempo al compilatore (che deve
capire cosa e` un commento e cosa invece e` codice), ma non certo
influire a run-time.


per ogni carattere di commento inserivo un ciclo di 100 NOP ;)
no comment.


scriveva sarebbe durato a lungo, cosi' e' nato il bug dell'anno 2000.
A proposito di design e di millenium bug: in uno dei suoi articoli (non ricordo
quale, sorry) C. Pescio discorreva sull'impatto che determinate scelte hanno
sull'evoluzione del sw. Prendendo come rif. il bug di cui sopra, disse qualcosa
del tipo "La colpa non era nella scelta della rappresentazione usata per
esprimere una data, dato che era perfettamente ragionevole operare così
all'epoca, visti i vincoli di memoria esistenti. Il disastro è causato, invece,
dall'aver distribuito questi dettagli di implementazione lungo tutto il codice.
Un design più accurato avrebbe consentito di localizzare il codice soggetto a
modifica, consentendo una manutenzione più agevole". Chiedo scusa all'autore se
ho riportato in modo vago il concetto (spero solo non ci siano inesattezze).
Questa è una visione delle cose che amo perchè incoraggia un'analisi critica
della situazione e non si ferma a scagliare il sasso nello stagno.


 PS: (domanda da ignorante) ma togliendo i commenti cosa si ottimizza?
che la CPU non perde tempo a leggere i commenti quando esegue il programma
:-))) ...ovviamente scherzo...
Questo era solo un esempio del modo in cui viene inseguito il miraggio delle
prestazioni senza avere la dovuta preparazione tecnica e senza muoversi
nella giusta direzione.
Personalmente io cerco di programmare nella maniera piu' naturale possibile,
nel senso che cerco di mantenere una struttura logica piu' vicina all'uomo
che alla macchina. Quando pompano sulle prestazioni faccio finta di niente e
codifico come dico io. Fino ad ora ho sviluppato qualche decina di
applicazioni e non ho mai avuto problemi.
Le prestazioni, comunque, se devo aumentarle, lo faccio alla fine con un
buon profiler che mi dice quanto tempo viene trascorso all'interno di una
funzione e quanto una funzione viene chiamata. A volte la soluzione puo' non
essere cambiare il codice ma scrivere alcune parti in altri linguaggi o fare
girare il programma su macchine piu' veloci.
Ciao
Emanuele Merlo

I commenti sono di solito la documentazione piu' aggiornata
dell'applicazione perche' si trovano direttamente sul codice ed e' facile
tenerli allineati.
Personalmente io commento molto ed anche ho speso un po' di tempo a cercare
un modo di commentare che fosse veramente utile. Certo che i piu' esperti
possono sempre leggere il codice, ma non e' detto che chi modifichera' la
mia applicazione sia esperto o che riesca a capire quello che volevo fare
senza fraintendere.
Alcuni sostengono che il loro stile di programmazione e' "autodocumentante"
(che il piu' delle volte non e' vero :-)) ), ma a volte qualche buona parola
in italiano aiuta molto.
Spiegare una funzione a parole aiuta inoltre a verificarne la struttura
logica. Se non si riesce a spiegare facilmente -secondo me- non e' stata ben
disegnata. Gli stessi commenti, inoltre, potranno essere utilizzati per la
stesura della documentazione, che di solito viene scritta molto tempo dopo
che si e' iniziato a codificare (e quindi molte finezze sono gia' state
dimenticate).
Non penso che scrivere i commenti sia una perdita di tempo perche' bisogna
tenerli allineati al codice, se l'analisi e' stata fatta bene, il codice non
dovra' essere modificato molte volte e quindi i commenti potranno rimangono
pressoche' identici.
Tornando sul discorso della velocita', infine, posso dire che sui libri di
qualita' del software che ho letto, c'e' scritto che le "porcherie" si
possono fare, ma che devono essere adeguatamente commentate (che per mia
esperienza e' impossibile).
Io resto dell'idea che, durante la stesura, la qualita' sia prioritaria
rispetto alla velocita', le ottimizzazioni si potranno fare alla fine con
migliori risultati.
Ciao
Emanuele Merlo

static int GetConfiguredBlocks( int aStartBlock, int aMaxCount, int aType,
TVarList pVarList[ ], TVarList pHDVarList[ ] )
 E' ovvio che questa funzione (ancora OINK!) serve a formattare l'HD alla
prima esecuzione del programma.
A parte gli scherzi, mandami anche la documentazione tecnica (ben fatta),
gli header (senza commenti) e probabilmente potrei farcela. In effetti davo
per scontato che bisognerebbe almeno avere un'idea di cosa faccia il
programma (analisi per esempio, ma mi sembra di averlo scritto).
Nel frattempo, se vuoi dare un'occhiata ad un'altra funzione (scritta da me
parecchi anni fa in C):
errsol carica_appuntamenti (appuntamento *inizio, appuntamento *fine){
E ti garantisco che questa era una delle più complicate. Vero che il
programma non era nel complesso granchè complesso (agenda tipo filofax), ma
penso sia abbastanza significativa.
Comunque sia mi scuso per il "rumore" provocato nel NG, prometto che in
futuro mi associerò all'opinione dei più.
--
Alessandro Monti
P.S.
Nel caso fosse utile, riporto anche i commenti ed il codice completo della
funzione sopra citata:
/* ******************************************
 Carica gli appuntamenti compresi tra due
 giorni da file e li mette nella lista_app.
 ******************************************
*/
errsol carica_appuntamenti (appuntamento *inizio, appuntamento *fine){
errsol esito;
appuntamento dati;
do{
 esito = risolto;
 if (!(file = fopen (fnome, "rb")))
  esito = errore (apertura);
}while (esito == riprova);
if (esito == risolto){
 while (!feof (file) && esito != annulla){
  esito = risolto;
  if (fread (&dati, sizeof (dati), 1, file))
   if (compreso (&dati, inizio, fine))
    inserisci_app (&dati);
   else ;
  else if (!feof (file))
   esito = errore (lettura);
 }
 fclose (file);
};
return esito;
}
In effetti probabilmente era già inequivocabile (a parte il riferimento alla
lista che non compare nei parametri: ero giovane e auto-ottimizzante...).
Mi scuso anche per la scarsa "rientranza" del codice, ma pare che il
copia-incolla di outlook trasformi i tab in spazi.

 dimenticate).
Anche questo è un buon argomento a favore dei commenti, ma niente ha che
fare con l'ottimizzazione "vera".
Mi sembra che questa sia la risposta più ragionata (non me ne vogliano gli
altri) tra quelle che ho ricevuto.
Poichè ho sostenuto l'inutilità dei commenti (sia pure solo a certi fini e
non in generale), mi è stato fatto un bell'elenco di motivi per cui invece
servono.
Speravo di avviare una discussione su questi toni, con opinioni meditate e
nate dopo aver letto con attenzione tutto il testo dei messaggi precedenti.
Mi sembra invece di aver trovato un branco di lupi pronti a sbranarti appena
fai un'affermazione che non gli garba, magari senza fermarsi a riflettere un
poco e magari senza finire la lettura.
Non mi aspettavo certo di sentirmi dare ragione (se no che provocazione è?)
ma neanche di essere assalito!
--
Alessandro Monti

 Questo il linea di principio.
Esatto, e anche senza eliminare il commento, utile per altre cose !=
dall'ottimizzazione (ma ormai dispero di farmi capire), il "cosa" dovrebbe
essere nella documentazione tecnica, non (o non solo) sul sorgente.
Opinione mia, ormai mi avete convinto che sbaglio. Pazienza, andrò a fare il
panettiere.
--
Alessandro Monti

 sviluppo non si fa più manutenzione.
Non mi sembra proprio! Sarebbe vero se avessi sostenuto che i commenti non
servono a niente o che l'unica manutenzione è l'ottimizzazione.
Poichè non è così, viva i commenti!
Però bisogna anche saper discernere a cosa sono utili le cose. Non basta
dire che una cosa è buona per concludere che è buona in qualunque contesto e
per qualunque fine.
I commenti saranno utili, magari anche indispensabili per una quantità
impressionante di motivi diversi, ma tra questi non figura l'ottimizzazione.
E' opinabile, d'accordo, ma se le critiche che ricevo sono solo cose del
tipo: "hai torto perchè servono a tutt'altro", vuol dire che non è stato
capito il concetto fondamentale che volevo esprimere. (non prendetela a
male, sicuramente mi sono spiegato male io, spero che adesso sia più chiaro)
--
Alessandro Monti

 nell'eseguibile.
Era un tema d'esame per TAMC (Teoria ed Apllicazioni delle Machine
Calcolatrici). In pratica prendeva in input un sorgente pascal e creava
l'equivalente in assembler. La parola "traduttore" se non addirittura
"compilatore" sarebbe più indicata, ma così era nel testo del progetto
(scritto da professori universitari, e chi sono io per criticarli?) e così
mi è rimasta "appiccicata addosso" quando parlo di quel programma. Credo sia
un anglicismo derivato dal verbo "to translate = tradurre".
A voler difendere il termine, si potrebbe considerare lo "spazio dei
programmi scritti in pascal" e lo "spazio dei programmi scritti in
assembler", e risultando il primo sottoinsieme del secondo (sto considerando
in realtà la funzione computata dai programmi scritti in pascal e quelli
scritti in assembler), risulta una trasformazione affine, e pertanto il
verbo "traslare" assume senso. Una proprietà interessante (e ovvia) di
questa trasformazione è che la funzione computata rimane la stessa!!!
Questo a voler difendere il termine, ma io non ho alcun interesse a farlo.
Comunque a questo punto capirai che, se anche nella totalità dei compilatori
i commenti non finiscono nell'eseguibile, nel mio invece ci finiscono
eccome, risultano in 100 istruzioni inutili (NOP=No OPeration, istruzione
che non fa niente a parte perdere tempo) per ogni carattere di commento.
Poco importa che in realtà questo non avvenisse nel mio programma (qualcuno
mi ha accusato di scarsa professionalità, ma non si trattava di professione
ma di studi, per cui sarebbe potuto essere del tutto legittimo), siete
sicuri di quello che fa il VOSTRO compilatore? Magari non penalizza la
velocità, ma la dimensione? Potrebbe memorizzare i vostri commenti in aree
non raggiungibili dell'eseguibile. O magari li ignora davvero. Fatto sta
che, almeno in teoria, è possibile che i commenti vadano a diminuire le
prestazioni.
Con ciò (lo preciso ancora una volta prima di ricevere altre rispostacce)
non voglio assolutamente dire che non bisogna scrivere i commenti.
--
Alessandro Monti

 programma in assembler non c'e` motivo di aggiungere cicli vari...
Lo so, e in effetti non lo faceva. In un altro post ho spiegato meglio
quest'altra provocazione (perchè, l'altra non bastava?).
Il punto è che "poteva" farlo, e se può farlo un compilatore scritto da me,
possono farlo tutti. (che poi non lo facciano è un'altro discorso).
Mi premeva dimostrare che è possibile che i commenti influiscano
negativamente sulle prestazioni run-time, non che questo avvenga realmente.
Noto adesso la firma "universitaria" purtroppo il sito indicato non
risponde. Peccato. In un altro messaggio avevo scritto che non ho intenzione
di contraddire un professore universitario, sarebbe averlo fatto
involontariamente.
--
Alessandro Monti

 Maguire in "Writing Solid Code".
Ammetto la mia ignoranza riguardo i libri citati e addirittura dei loro
autori. Se comunque non ho capito male il riferimento, posso dirti che c'è
chi sostiene che un'analisi ben fatta E' il programma. Per cui niente
codice, niente commenti. Il punto debole è ovviamente che mancano gli
strumenti perchè questo sia attuabile in pratica. (almeno per ora)
I nomi non te li faccio, tanto sono concetti noti, che un qualsiasi libro di
ingegneria del SW riporta.
Tanto per prevenire domande, cito UML (e quindi i suoi creatori). Uno dei
principi ispiratori di UML
--
Alessandro Montiè di avvicinarsi a questo obiettivo.

 E' più chiaro il mio ragionamento?
Francamente no. Per due motivi: non sono d'accordo sul fatto che sia
inutile scrivere commenti per le future ottimizzazioni, e questo si è
capito; inoltre non vedo come tu possa dire quale sia lo scopo delle
future modifiche di un programma. Certo, se per le future modifiche i
commenti saranno inutili allora è inutile anche scriverli; così come se
domani finisce il mondo è inutile scrivere il programma :-)


involontariamente.
Non sono un docente... e comunque non c'e` nulla di male nel ribattere
le affermazioni di un docente, possono sbagliare anche loro anche se
e` molto piu` facile che a sbagliare sia lo studente.


futuro mi associerò all'opinione dei più.
La discussione è utile se è intrapresa con un fine chiaro a tutti e se viene
condotta con toni costruttivi. E' più importante stimolare una riflessione
intelligente che avere ragione. E poi la ragione raramente sta tutta da una
parte, quindi siamo tutti salvi... :-)
Ciao


 e` molto piu` facile che a sbagliare sia lo studente.
Concordo.
Mi è rimasta una parola inceppata tra le dita e la tastiera:
"sarebbe (curioso) averlo fatto involontariamente"
Comunque dopo poco ha ripreso a funzionare il sito. (ogni tanto un po' di
insonnia serve a qualcosa)
--
Alessandro Monti

 parte, quindi siamo tutti salvi... :-)
Se è per questo, era lo scopo del mio post. Sapevo in partenza di avere una
posizione difficilmente difendibile (anche perchè partivo da una
dichiarazione del tipo "chi dice queste cose è ignorante"), però mi sembra
che alla fine si sia evoluta bene.
Non accetto solo che mi si attribuiscano opinioni che non ho espresso (e
errate). Se si vuole criticare un opinione si ragioni su quella, non su
altre conclusioni non giustificate (come chi ha dedotto che non sapessi come
opera un compilatore).
E' come dire: non so come dimostrarti che sbagli, ma credo di aver trovato
un'altra cosa in cui sbagli e perciò sbagli su tutto.
Per concludere, ho già detto che anche io uso i commenti (che siano fatti
bene o no non posso giudicarlo).
Mi avete "quasi" convinto che servono anche per l'ottimizzazione.
--
Alessandro Monti

Secondo me e' un errore pensare che una applicazione debba essere sempre
ottimizzata attraverso il codice e gli algoritmi. Con l'avvento della
programmazione ad oggetti lo sviluppo del software e' cambiato moltissimo,
non solo per l'organizzazione e la portabilita' del codice, ma anche nella
stesura. Una volta chi doveva implementare una lista doveva scrivere piu' o
meno dall'inizio alla fine tutto il codice, oggi istanzia un oggetto di tipo
CList e lo personalizza (in Windows, NdR).
Di solito gli algoritmi migliori sono gia' implementati all'interno delle
librerie di "oggetti" che sono rese disponibili con i vari ambienti di
sviluppo ed e' difficile riuscire a fare qualcosa di migliore.
Anche nel caso in cui le suddette librerie non siano disponibili, le cose
non cambiano molto, la maggior parte degli algoritmi efficienti sono
raccolti in molti libri e ampiamente documentati, basta trascriverli ed il
codice difficilmente dovra' essere modificato per avere piu' velocita' (a
meno che non si sia scelto l'algoritmo sbagliato, ma questo e' un altro
discorso).
Se, quindi, siete d'accordo come me che poco spazio puo' essere lasciato
all'ottimizzazione degli algoritmi, torniamo all'affermazione iniziale: "e'
meglio favorire la qualita' del software rispetto alle prestazioni".
Qualche parola infine sui commenti (che ritengo indispensabili), prendiamo
per esempio il seguente codice:
for (i = 0; i < MAXCOLORS; i++)
    szAttr[i * 2] = szAttr[(i * 2) + 1] = i << 4;
(parte della funzione "demoFillAtt" - Platform SDK/Sample Code - MSDN Visual
C++ 6.0)
indipendentemente da quello che fa' fisicamente o il motivo per cui e' stato
scritto, e' molto meglio trovarselo davanti scritto cosi':
  /* construct the attribute string */
  for (i = 0; i < MAXCOLORS; i++)
    /* for each set of two, the color attributes are in the high byte */
    /* of the word - shift them into the high byte */
    szAttr[i * 2] = szAttr[(i * 2) + 1] = i << 4;
Scrivere i commenti non e' costato nulla, ma aiuta molto quando si deve
interpretare queste due righe ed evita molta confusione.
Ciao
Emanuele Merlo

 interpretare queste due righe ed evita molta confusione.
Certamente (l'ho ripetuto poco, forse?) i commenti sono utilissimi per la
comprensione, ma il punto era se fossero utii per l'ottimizzazione. Sempre
che abbia senso per te fare questa distinzione.
Grazie per l'argomento nuovo.
Pensavo che la discussione fosse ormai esaurita, invece qualche spunto nuovo
fa sempre piacere.
Chissà perchè in questo thread mi riesce solo di contraddire la gente...mah!
Spero che nessuno se la prenda a male.
--
Alessandro Monti

 interpretare queste due righe ed evita molta confusione.
D'accordissimo che i commenti in questi casi sono un aiuto incredibile.
Meno d'accordo sul fatto che non costi niente scriverli...
EMG

Spero che nessuno se la prenda a male.
Peccato, stavolta non sono riuscito a farmi venire un attacco di bile :)

 meglio favorire la qualita' del software rispetto alle prestazioni".
Dipende molto dal dominio dell'applicazione.
A volte e' necessario sacrificare un po' la qualita', intesa come
leggibilita' e facilita' di manutenzione, a vantaggio delle prestazioni.
MM

 non essere sufficiente.
  Io su questo non sono molto d'accordo. Sto lavorando da circa 1 anno ad
  una applicazione real-time (simulatore di motociclista) 
  dove l'efficienza e` probabilmente la cosa
  piu` importante (almeno quando l'applicazione entra in un certo stato).
  Ovviamente non posso mettermi a fare cose tipo ordinamenti di vettori
  o altre cose "pesanti", ma quello che limita di piu` l'efficienza
  e` proprio fare chiamate a routine di sistema. Ad esempio la primitiva
  sendto per la spedizione di un messaggio in broadcast (UDP), anche se
  su rete  ethernet isolata dal resto del mondo, e` piuttosto 
  lenta (anche se a livello UDP non dovrei avere problemi legati a
  ritrasmissioni in quanto il protocollo non dovrebbe garantire niente).
  Nel codice della applicazione c'e` persino una funzione ricorsiva per una
  visita su un albero (anche se di profondita` 2). Garantisco che questa
  funzione impiega un tempo del tutto trascurabile risspetto a una
  chiamata ad una sendto. Anche funzioni per la creazione/distruzione di
  task impiegano tempi molto grandi, al punto che abbiamo dovuto decidere
  di creare all'inizio tutti i task che ci servono e distruggerli solo
  quando l'applicazione termina, anche se alcuni di tali task per un
  certo periodo non fanno altro che andare in esecuzione, vedere che non hanno
  niente da fare e quindi bloccarsi di nuovo.
  Unica eccezione a quanto sopra e` costituita dalle routine (scritte dai
  programmatori) che servono per cambiare sistema di riferimento 
  (posizione del motociclista, intesa in termini di posizione x,y,z, angoli
   di roll. pitch e yaw  e angolo dello sterzo, velocita` in termini ancora
  di x,y,z,roll,pitch e yaw e accelerazione), anche perche` ci sono
  4-5 sistemi di riferimento e ogni modulo della applicazione lavora
  nel sistema che preferisce. In questo caso le routine di conversione sono
  effettivamente piuttosto pesanti.
 Marco Guidi
 

   chiamata ad una sendto. 
Questo riporta a quello che dicevo io riguardo alle ottimizzazioni. Piů
o meno tutte le applicazioni hanno i loro colli di bottiglia. A meno di
clamorosi errori o casi particolari, č difficile che l'implementazione
degli algoritmi rappresenti un punto veramente critico nelle prestazioni
del programma. Ribadisco, ovviamente a meno di errori clamorosi o di
casi particolari.
La maggior parte delle volte per "ottimizzazione" si intende individuare
i colli di bottiglia e ridurli in modo da influire meno possibile sulle
prestazioni del programma. 
Tempo fa avevo fra le mani una parte di codice di una applicazione
web-server, questo codice eseguiva il parsing di un file HTML in memoria
per sostituire alcuni tag e quindi lo spediva al client. Apparentemente,
il parsing era critico perchč i file potevano essere anche decine di k e
faceva uso intensivo di copie in memoria. Ad un esame neanche troppo
approfondito scoprii che il tempo impiegato per il parsing era
trascurabile anche rispetto al tempo necessario ad aprire un socket. 


Eh si, devo darvi ragione, quando ho scritto pensavo a funzioni di grafica
che sono gia' ottimizzate all'osso, per molte altre non posso che essere
d'accordo con voi.
Per quanto riguarda l'ottimizzazione tramite gli algoritmi, presupponevo
un'analisi corretta (che pero' e' un'utopia :-) ). Comunque, per esperienza,
ho visto che le ottimizzazioni non sono quasi mai fatte perche' sono
cambiate le necessita, ma perche' non e' stato speso neppure un minuto a
pensare quante risorse venivano consumate e presupponendo che la propria
applicazione fosse l'unica a venire eseguita nel sistema.
Continuo ad essere intransigente, invece, sui commenti. L'esempio di codice
che ho riportato era volutamente ben scritto, ma comunque bisognava spendere
del tempo per capire cosa faceva, da cosa partiva e dove finiva. Nella
realta' le cose strane sono sparse in routine drammaticamente lunghe :-))
dove le variabili si chiamano i, j, p per non dire pippo, pluto e paperino
(gia' visto, giuro).
Tanto per dare un'idea:
 while ( esegui_loop )
{
if ( (liv_ric*(Nu-Necc) + Nu - liv_ric - Necc)*(Nu-marg1) >= Npr )
  break;
if ( (Nu-marg1-Necc-(liv_ric+1)) > (INTEGER) (traffico/capienza) &&
    terzo_passo)
  {
  liv_ric+=1;
  continue;
  }
if ( (liv_ric*(Nu-Necc) + Nu - liv_ric - Necc)*Nu >= Npr )
  break;
if ( (Nu-(liv_ric+1)) > (INTEGER) (traffico/capienza) && terzo_passo)
  {
  liv_ric+=1;
  continue;
  }
if (!terzo_passo)
  break;
if ( ((Nu <= 2*liv_ric) &&
     (Nu) > (INTEGER) (traffico/capienza) )
     ||
     (Nu-liv_ric) > (INTEGER) (traffico/capienza) )
  {
  sprintf(error_buffer, GS1_ERR_RANGE_CLU, input_file);
  STOP(error_buffer);
  }
else
  {
  sprintf(error_buffer, GS1_ERR_REDUCE_SPLIT, input_file);
  STOP(error_buffer);
  }
}
questa e' solo una parte di una grossa funzione riportata cosi' come l'ho
trovata (e non e' neppure delle peggiori). Secondo me neanche chi l'ha
scritta ci capisce qualcosa a colpo d'occhio, comunque, a voi i commenti...
(perdonate il gioco di parole :-) )
ciao
emanuele

 if ( (liv_ric*(Nu-Necc) + Nu - liv_ric - Necc)*(Nu-marg1) >= Npr )
if ((Nu *(1+liv_ric) - Necc *(1+liv_ric) - liv_ric)*Nu-marg1) >= Npr)
Che è più facilmente ottimizzabile dal compilatore. (e volendo si può
calcolare prima e una sola volta (1+liv_ric))
Ovvio che non capendoci niente (ma l'analisi e la documentazione dove sono?
Ne avessi vista una, ben fatta) non potrei adesso cambiare l'algoritmo, ma
qualcosina già si guadagna. A proposito, ma le dichiarazioni di variabili
dove stanno? E il prototipo della funzione? Avevo già espresso chiaramente
che questi dovrebbero dare molte indicazioni. (a meno di chiamarle pippo())
Concordo sui motivi dell'ottimizzazione, ma si sa che ogni programma, per
girare bene, dovrebbe essere l'unico in esecuzione sulla faccia della terra
:)
--
Alessandro Monti

trovata (e non e' neppure delle peggiori).
Purtroppo la programmazione procedurale incoraggia le funzioni molto
lunghe, uno dei pregi della OOP e` (IMO) il fatto che invece incoraggia
funzioni corte.


  Io su questo non sono molto d'accordo.....
Certamente, il mio era un discorso generico. Ci possono essere molti
casi in cui e' vero il contrario, come il tuo. Aggiungerei che per certe cose
non ci si puo' nemmeno aspettare piu' tanto, ad esempio la apertura
di canali di comunicazione in rete non puo' essere certo una cosa veloce.
In certi casi, la soluzione migliore potrebbe essere quella di fare, se
possibile,  come hai fatto per il problema dell'attivazione dei vari task;
magari puoi aprire tutti i socket che ti servono all'inizio e chiderli solo 
alla fine.

Paperino :)
Sai quanti pippo.c, pippo.cpp, pippo.exe, pippo.dat ecc. sono sul mio hd? :)
Marco

funzioni corte.
E dove sta scritto? Io mi sono sempre fatto un vanto di tenere le
funzioni delle mie applicazioni procedurali in una schermata sola;
ci riesco nel 90% dei casi.

ci riesco nel 90% dei casi.
Studi statistici...
La presenza di funzioni lunghe e` molto piu` alta in linguaggi 
procedurali. In linguaggi OO il meccanismo dell'ereditarieta`
tende a favorire la realizzazione di strutture complesse per gradi
riducendo cosi` la possibilita` di trovare funzioni lunghe.
Ovviamente in entrambi i casi molto dipende anche dal programmatore!
Se non erro ad un discorso del genere accennava anche C. Pescio,
mi pare nel suo libro...


 Paperino :)
Ci credo!! io agli albori avevo un C64 e 8 anni :-)))
Ciao
Emanuele

 Ci credo!! io agli albori avevo un C64 e 8 anni :-)))
Beato te che hai cominciato cosě presto. Io ora ho 18 anni di esperienza
ma se avessi iniziato ad 8 anni ora ne avrei 31! Sarei un mostro...
EMG

ma se avessi iniziato ad 8 anni ora ne avrei 31! Sarei un mostro...
Ok, abbiamo capito che sei vicino agli 'anta  ;)
non fare cosi` tanto prima o (meglio) dopo ci arriviamo tutti!
