Newsgroup: it.comp.programmare
Titolo: [CONFRONTO] Python vs C con algoritmi di sorting (prova comparativa)

SOMMARIO
Quello che segue e' un test sia sulla velocita' del Python, per cio' che
attiene l'esecuzione, che un confronto tra due algoritmi di sorting, uno
"generale" ed uno "contestualizzato". L'obiettivo che si propone questo test
e' quello di:
a) dimostrare che la natura interpretata di Python inficia le prestazioni;
b) dimostrare che il livello di astrazione di Python introduce problematiche
prestazionali.
Ovviamente il test non vuole dimostrare che il codice scritto in Python sia
il migliore in assoluto! D'altra parte, fornisce anche un feedback riguardo
la presunta "facilita'" di scrittura che si ha con il linguaggio medesimo.
AMBIENTE OPERATIVO
    PIII 1000 Mhz con 256 Mb di RAM
    Windows NT 4.0 SP6
    Visual C++ 6.0 SP3
    Python 2.2.2b1 (per Windows 32)
PROBLEMA APPLICATIVO
Si abbia un sistema di acquisizione segnali A/D che produce circa
MAX_SAMPLES campionamenti al secondo con 8 bit di precisione. Si abbiano
MAX_REPEATS sistemi di acquisizione in parallelo. Si vuole operare un
ordinamento del flusso di informazioni in arrivo. L'ordinamento deve essere
dal piu' piccolo al piu' grande.
ALGORITMI IN PROVA
* Algoritmo fornito dalla libreria (sort( ) su sequenze per il Python,
qsort( ) generico per C).
* Algoritmo contestualizzato (basato sul fatto che i valori da ordinare
hanno range 8 bit, 0...255).
SORGENTI
Vedi allegato 1.
AMBIENTE DI MISURA
La misurazione avviene contando il numero di secondi tra l'inizio del
processo ed il suo termine, ed e' incluso nel sorgente medesimo. I parametri
di testing sono il numero di cicli, MAX_REPEATS, ed il numero di
campionamenti in un secondo, MAX_SAMPLES. I due tempi riportati si
riferiscono, rispettivamente, al primo algoritmo ed al secondo (il parametro
"fast" della funzione "experiment"). I tempi sono riferiti come media tra
tre esecuzioni consecutive (per evitare l'influenza dei cache missing).
MISURE
    MAX_REPEATS  = 1
    MAX_VALUES = 10000
        Python = 0.165 s, 0.178 s
        C = 0.015 s, 0.000 s
    MAX_REPEATS  = 10
    MAX_VALUES = 10000
        Python = 1.667 s, 1.781 s
        C = 0.12 s, 0.000 s
    MAX_REPEATS  = 10
    MAX_VALUES = 20000
        Python = 3.38 s, 3.592 s
        C = 0.22 s, 0.01 s
CONCLUSIONI
Le conclusioni sono:
a) la natura interpretata di Python inficia le prestazioni a livello
strutturale (introducendo un rallentamento di un fattore 10);
b) il livello di astrazione di Python introduce problematiche prestazionali
in caso di algoritmi contestualizzati (l'algoritmo pur essendo sulla carta
piu' efficiente viene eseguito in un tempo maggiore, con un rallentamento
del 5%);
c) il rapporto di velocita' tra compilato C e Python e' >= 10.
d) il rapporto di produttivita' (numero di linee di codice) e' di 33 contro
45, ovvero meno del 74%, ovvero circa 1.37 (< 1.5).
Saluti!
*** Azimuth ***
Appendice 1 - Sorgente in Python
import time
import random
MAX_REPEATS = 10
MAX_SAMPLES = 20000
MAX_VALUES = 256
def prepare( ) :
    samples = [ ]
    for s in range( MAX_SAMPLES ) :
        samples.append( int( random.random() * 256 ) )
    return samples
def library_sort ( samples ) :
    samples.sort();
    return samples
def fast_sort ( samples ) :
    buffer = [ ]
    for s in range( MAX_VALUES ) :
        buffer.append( 0 )
    for x in range( MAX_SAMPLES ) :
 buffer[ samples[ x ] ] = buffer[ samples[ x ] ] + 1
    x = 0
    for y in range( MAX_VALUES ) :
 while buffer[ y ] > 0 :
     samples[ x ] = y
     x = x + 1
     buffer[ y ] = buffer[ y ] - 1
    return samples
def experiment( fast ) :
    if ( fast == 0 ) :
        for t in range( MAX_REPEATS ) :
            library_sort( prepare( ) )
    else:
        for t in range( MAX_REPEATS ) :
            fast_sort( prepare( ) )
if __name__ == "__main__":
    c = time.clock()
    experiment( 1 )
    d = time.clock() - c
    print "It tooks"
    print d
    print " to perform."
Appendice 2 - Sorgente in C
#include <stdio.h>
#include <time.h>
#include <stdlib.h>
#include <memory.h>
#define MAX_REPEATS  10
#define MAX_SAMPLES  20000
#define MAX_VALUES  sizeof( unsigned char ) * 256
unsigned char samples[ MAX_SAMPLES ];
void prepare( void ) {
 int s;
 srand( time( NULL ) );
 for( s = 0; s < MAX_SAMPLES; ++s )
  samples[ s ] = rand( ) >> 1;
}
int compare( const void * _e1, const void * _e2 ) {
 return (* (unsigned char *) _e1 ) < (* (unsigned char *) _e2 );
}
void library_sort( void ) {
 qsort( &samples, MAX_SAMPLES, sizeof( unsigned char ), compare );
}
void fast_sort( void ) {
 int buffer[ MAX_VALUES ];
 int x, y;
 memset( buffer, 0, MAX_VALUES * sizeof( int ) );
 for( x = 0; x < MAX_SAMPLES; ++x )
  ++buffer[ samples[ x ] ];
 x = 0;
 for( y = 0; y < MAX_VALUES; ++y )
  for( ; buffer[ y ]; --buffer[ y ] )
   samples[ x++ ] = y;
}
void experiment( int _fast ) {
 int t;
 if ( ! _fast ) {
  for( t = 0; t < MAX_REPEATS; ++t ) {
   prepare( );
   library_sort( );
  }
 } else {
  for( t = 0; t < MAX_REPEATS; ++t ) {
   prepare( );
   fast_sort( );
  }
 };
}
int main( ) {
 clock_t c = clock();
 clock_t d;
  experiment( 1 );
 d = clock() - c;
 printf( "It tooks %f to performs", ( float ) d / ( float )
CLOCKS_PER_SEC );
 return 0;
};

 prestazionali.
Falso. Scrivimi la gestione di un dizionario in C e vediamo se riesci a
renderla efficiente, dal punto di vista prestazionale, quanto quella di
Python.
Al solito, non riesci a dimostrare nulla di concreto.
--------------------------------
Inviato via 
http://usenet.libero.it

 [...]
Senti, i numeri stanno li', i metodi di misura anche e ci sono persino i
sorgenti.
Controbatti seriamente ed evita di impestare il NG!
*** Azimuth ***

 Senti, i numeri stanno li', i metodi di misura anche e ci sono persino i
Con il piccolo particolare che i tuoi numeri *non dimostrano* cio' che vuoi
dimostrare.
Sai, un dettaglio.


 Sai, un dettaglio.
Si', si'...
*** Azimuth ***

 *** Azimuth ***
lascialo perdere litiga sempre con tutti senza dire nulla di utile :))
ciao :)

 sorgente, con tools che compilano?
Tu hai semplicemente compilato due programmi scritti in due linguaggi
diversi, con due implementazioni diverse, e ne hai confrontato i timings,
non mi sembra un granche' di esperimento.
Tra parentesi, quando fai dei benchmark, impara sempre a specificare i
compilatori, le piattaforme e i sistemi operativi utilizzati.
Probabilmente non ti sei accorto (non me ne meraviglio, vista la lentezza
delle comunicazioni sinaptiche dei tuoi neuroni) che io non sto confutando i
tuoi numeri, nonostante ti stia dando torto.
Dov'e' l'inghippo allora ? dai confido che tu abbia ancora un ultimo barlume
di intelligenza per scoprirlo...... hmm... no, dai, mi sono ricreduto, te lo
spiego io: l'inghippo e' nel fatto che, nonostante la stima dei tempi sia a
favore del codice C, tu non dimostri la tua teoria originale.
Sei forse arrivato alla conclusione che il codice di un linguaggio, se viene
interpretato, anziche' compilato, e' piu' lento ? Non mi sembra una grande
scoperta, lo sapevamo gia'.
Ti ricordo che hai affermato:
"a) dimostrare che la natura interpretata di Python inficia le prestazioni;"
La natura "interpretata" e' del codice, non del linguaggio.
Il linguaggio, in se', non e' definibile ne' "interpretato", ne'
"compilato", e' l'*implementazione* che determina in che modo il codice
verra' eseguito.
Io posso costruire un compilatore Python (chi me lo impedisce ?) che produce
codice nativo, di gran lunga piu' efficiente del codice C, generato da un un
interprete C.
Posso scrivere un compilatore Python che produce codice nativo piu'
ottimizzato di un compilatore C, ecc... ecc... ecc...
Non e', quindi, il linguaggio in discussione, e' la sua implementazione
specifica.
"b) dimostrare che il livello di astrazione di Python introduce
problematiche
prestazionali."
Per i motivi di cui sopra, le PROBLEMATICHE PRESTAZIONALI (oooohhh stupore)
non sono **AFFATTO** correlate al livello di astrazione di Python. Non e'
possibile affermare aprioristicamente che un livello di astrazione introduca
dei problemi a livello di prestazioni.
Supponi che io abbia un'implementazione di un dizionario in C (esempio,
potrei costruire qualcosa di simile al template map del C++) e abbia del
codice Python che sfrutta un dizionario.
Stando al tuo ragionamento, il problema di prestazioni e' attribuibile al
linguaggio.
Bene, se fosse cosi', dovrei avere che, un codice che sfrutta un dizionario,
in Python, dovrebbe essere comunque e sempre (perche' prescinde dal
compilatore/interprete, e' una questione di linguaggio, secondo te), in
qualsiasi modo venga tradotto/compilato, piu' lento dell'equivalente codice
C.
Falso, ovviamente, controprova: traduco con un compilatore come il 211 il
codice Python in un equivalente codice C, lo compilo ed ho *ESATTAMENTE* gli
stessi tempi.
Il livello di astrazione che ho usato nel codice Python e' alto (perche' il
dizionario e' una struttura molto astratta) e la prestazione che ho avuto e'
ottima.
Tesi: il livello di astrazione del linguaggio NON puo' inficiare
*ALCUNCHE'*.
Come volevasi dimostrare.


"Azimuth" ha scritto
: 
: int compare( const void * _e1, const void * _e2 ) {
: 
:  return (* (unsigned char *) _e1 ) < (* (unsigned char *) _e2 );
: 
: }
: 
: 
: void library_sort( void ) {
: 
:  qsort( &samples, MAX_SAMPLES, sizeof( unsigned char ), compare );
: 
: }
: 
Ma la funzione di confronto che si passa a qsort non dovrebbe restituire
un valore maggiore, uguale o minore di 0. Questa mi sembra che restituisca
0 o 1. Io e` da un po` che non uso il C, per cui potrei sbagliarmi, ma
non mi sembra corretto.
ciao
Massimo

 un valore maggiore, uguale o minore di 0.
Hai ragione! La funzione compare va cosi' modificata:
int compare( const void * _e1, const void * _e2 ) {
    return (* (unsigned char *) _e1 ) - (* (unsigned char *) _e2 );
}
Comunque i tempi rimangono uguali, semplicemente l'ordinamento non era
corretto.
Questa patch influisce solo sulla funzione "library_sort" visto che
"fast_sort" non ne fa uso.
Ciao!
*** Azimuth ***

 33 contro 45, ovvero meno del 74%, ovvero circa 1.37 (< 1.5).
A parte che non puoi fare un confronto tra codice c scritto da un 
esperto e codice python scritto da un principiante, un confronto serio 
dovrebbe essere fatto su progetti un po' più complessi.
Altrimenti confrontando:
---- allegato a ----
#include <stdio.h>
void main()
{
    	printf("hello world");
}
----
con:
---- allegato b ----
print "Hello World";
----
possiamo concludere che python permette di scrivere un sesto delle 
righe richieste dal corrispondente programma in C.
-- 
Valter Minute
vmi...@inwind.it
 (the reply address of this message is invalid)

 dovrebbe essere fatto su progetti un po' più complessi.
Infatti ho scritto nella prova:
    "Ovviamente il test non vuole dimostrare che il codice scritto in Python
sia
    il migliore in assoluto! D'altra parte, fornisce anche un feedback
riguardo
    la presunta "facilita'" di scrittura che si ha con il linguaggio
medesimo."
Ora, spiegami perche' dovrei imparare ad ottimizzare in Python quando lo so
fare con il C?
Ciao.
*** Azimuth ***

 contrario e saro' ben felice di rivedere le mie misurazioni.
Le tue misurazioni non dimostrano cio' che vorresti dimostrare e quindi,
anche rivederle, non porta a nulla di concreto.
p.s.: in Python, la cosa piu' vicina a un array (ma molto piu' potente di un
array) e' la lista.


 array) e' la lista.
Quant'e' il costo di accesso in una lista? Lineare o costante? Come
modifichi il sorgente del Python?
*** Azimuth ***

 Quant'e' il costo di accesso in una lista? Lineare o costante?
Costante. In Python la lista subisce indicizzazione (subscript).


 Costante. In Python la lista subisce indicizzazione (subscript).
Visto che mi sono spulciato tutta la documentazione delle librerie del
Python ma non ho trovato nulla, mi dai i costrutti per la costruzione di una
lista?
*** Azimuth ***

lista?
scaricati i sorgenti
--
Rhymes (
rhymes_...@myself.com
)
http://www26.brinkster.com/rhymes
http://bw-crema.blogspot.com

 scaricati i sorgenti
Se non mi date delle informazioni specifiche alle mie domande, vuol dire tre
cose:
1) che non siete informati sui fatti, e allora smettere di apportare rumore
al thread;
2) che sapete che se uso l'informazione che mi date le cose non cambiano
molto, e allora siete in malafede;
3) che non volete darmele perche' le ritenete di importanza strategica, e
allora vedi al punto 1.
*** Azimuth ***

 
Perchè in python puoi usare in modo più semplice strutture complesse, i 
database, la GUI etc. e questo ti permette di ridurre i tempi di 
sviluppo.
A volte, l'ottimizzazione che puoi raggiungere con il C non vale il 
tempo che ci metti a svilupparla. Altrimenti tutti scriveremmo 
applicazioni solo in assembler.
Se questo nel tuo ambito professionale non succede mai, continua a 
utilizzare sempre e solo il C e a vivere felice, senza però pretendere 
di far usare solo il tuo martello da carpentiere anche a spazzini e 
ingegneri nucleari.
*A meno che qualcuno non voglia mettere 10 (20,50 o 100) PC a 
riordinare array di interi a 8 bit (cosa ben diversa dell'argomento di 
cui si discuteva).


 al thread;
Ma tu guarda da che pulpito viene la predica: il toro che dice cornuto
all'asino.
Noi siamo i male informati e noi produciamo rumore ? guarda che chi si sta
affannando nella gabbietta, sulla ruota, sei tu. Il rumore viene dalle tue
zampette che corrono. Noi stiamo qua e ti osserviamo. Gli errori che fai
(ormai li portiamo via a sporte) sono errori "di fondo", e' la filosofia (se
proprio la si vuol ritenere tale) alla base del tuo ragionamento che e'
sostanzialmente bacata. E' inutile che adesso cerchi di arrampicarti sugli
specchi.
Ricordati che se vuoi criticare qualcosa, quel qualcosa lo devi conoscere.
Nei vari thread hai raccontato di conoscere Python e di averlo scartato,
perche' non ti piaceva. **Ora**, invece, ti affanni a cercare di impararlo ?
e impararlo per che cosa ? per dimostrare l'indimostrabile ? Dovevi farlo
prima di cominciare a sparare a zero.
Capisco che gente come te abbia poche opportunita' per fare bella figura nel
mondo reale, ma ti ricordo che il capitano Ahab, a furia di inseguire Moby
Dick, si e' insabissato con lei.
Per quanto altro tempo dovremo sorbirci questa peste bubbonica ? :)
E dire che la documentazione di Python e' pubblicamente reperibile ;)


 corretto.
questo sembra confermare quello che si sta dicendo da alcuni giorni:
1) il C e` decisamente piu` veloce di python (eccezion fatta per le 
estensioni scritte in C le quali, evidentemente, sono veloci quanto il C 
:-), e questo non lo mette in dubbio nessuno.
2) python aiuta a scrivere codice migliore (dove con migliore *non* 
intendo efficiente, ma: corretto, manutenibile, leggibile, ecc.).
Essendo di piu` alto livello sono necessarie meno linee per realizzare le 
stesse operazioni: meno linee significano anche meno bug. Benche` tu 
abbia (immagino) anni di C alle spalle hai commesso un errore nel 
programma in C, cosa che in python (che conosci presumibilmente da molto 
meno tempo) non hai fatto.
uno degli "assiomi" dell'informatica e` che l'80% del tempo e` speso nel 
20% del codice: sembrerebbe che la cosa piu` sensata da fare si scrivere 
il 20% del codice-collo-di-bottiglia in C e il resto in python, no?
ciao Anto
-- 
"Computer science is not about computers any more than astronomy
is about telescopes." -- EW Dijkstra

>> print array.__doc__
This module defines a new object type which can efficiently represent
an array of basic values: characters, integers, floating point
numbers.  Arrays are sequence types and behave very much like lists,
except that the type of objects stored in them is constrained.  The
type is specified at object creation time by using a type code, which
is a single character.  The following type codes are defined:
[cut]


: Quello che segue e' un test sia sulla velocita' del Python, per cio' che
: attiene l'esecuzione, che un confronto tra due algoritmi di sorting, uno
: "generale" ed uno "contestualizzato". L'obiettivo che si propone questo 
: test
DEcisamente un lavoro ben fatto, Azimuth! A questo punto non ci sono 
proprio più motivi per scegliere il Python! Se prima avevo dei dubbi 
sulla possibilità di un compromesso tra velocità e manutenibilità, 
direi che i tuoi test sulle performance me li hanno dissolti: è meglio il 
C/C++, decisamente.
Grazie mille per lo sforzo e a buon rendere!
Fed.

 il 20% del codice-collo-di-bottiglia in C e il resto in python, no?
Io me la ricordavo come "il 10% del tempo lo impiegi a scrivere il 90% del
codice, mentre il restante 90% del tempo lo impieghi per il restante 10% del
codice". In ogni caso, il vero problema e' che, in fase di progetto, non e'
possibile capire cosa va in C e cosa va in Python, solo dopo, con un
profiling (come giustamente ha detto Alex Martelli) puoi capire dov'e' il
collo di bottiglia -- ma a quel punto la frittata e' fatta! Non puoi
modificare l'intera infrastruttura ma permetterti solo di "limare gli
spigoli".
Ciao!
*** Azimuth ***
[1] Se ti servono riferimenti, prova a vedere i test case descritti da
Pressman (mi pare che si chiami cosi') nel suo trattato sull'Ingegneria del
Software, che trascende il linguaggio utilizzato.

 sostanzialmente bacata.
Non mi sembri sufficientemente titolato per fare affermazioni di questo
genere.
*** Azimuth ***

> Questo test non dissolve minimamente i dubbi sulle tue affermazioni.
Ti sarei grato se sapessi produrre una documentazione che io possa ripetere
sulla mia installazione in modo da darti ragione.
Altrimenti e' aria fritta.
Ciao.
*** Azimuth ***

> Grazie mille per lo sforzo e a buon rendere!
Non c'e' di che!
*** Azimuth ***

 an array of basic values: characters, integers, floating point
"efficiently" e' un parolone. :)
Ho riscritto il programma di test sull'ordinamento con l'uso del tipo
"array", come mi hai suggerito. La semplice sostituzione al posto della
sequenza non e' ovviamente praticabile in quanto si viene a perdere il
"sort( )" nativo. Quindi ho operato una misura del solo algoritmo
"fast_sort()", e ho visto che i tempi sono addirittura PEGGIORI: 8 secondi
circa rispetto ai 7 misurati con l'uso delle sequenze. Inoltre, ho provato
anche a modificare l'algoritmo, cercando di far eseguire alla funzione di
libreria "count( )" di "array" il conto delle occorrenze: lasciamo perdere
(come tempi di esecuzione)...
*** Azimuth ***

 ripetere sulla mia installazione in modo da darti ragione.
Un test serio richiede tempo, mezzi e conoscenze. 
Tre cose che al momento non ho. 
E non ho nemmeno voglia di sentirmi dare ragione. Sono tremendamente 
pigro.
Non mi costa molto dire che ho torto, che mi hai aperto gli occhi e   
che mi fa male il culo per una caduta da cavallo dalle parti di 
damasco*. 
Mi scuso per averti fatto perdere tempo con questa discussione 
inutile e allargo le scuse a tutti i membri di questo ng che provvedo 
ad abbandonare a gambe levate promettendo ti tornarci solo quando 
avrò la competenza necessaria per disputare con gente come te, che 
sei il mago dei numeri e sei riuscito a dimostrare con 98 linee di 
codice che usare il C/C++ è sempre la cosa giusta da fare.
Mi limito a notare che, come d'abitudine, hai tagliato il resto del 
messaggio e tutte le mie osservazioni sulla validità del tuo 
esperimento.
Adesso però rimettiti la parrucca ed il naso rosso e torna al lavoro.
*non posso dirti che mi hai mostrato la luce perchè tu dovresti 
essere un cantante funcky e io dovrei indossare un completo scuro e 
piroettare dentro una chiesa di chicago. Te l'ho detto che sono 
pigro.


 esperimento.
Quali osservazioni?
Quelle di una persona che non ha "conoscenze" (ti cito)?
Sai, anche io sono pigro.
Non mi va di perdere tempo con chi cerca di contestare qualcosa, ma dimostra
e dichiara di essere ignorante sull'argomento medesimo.
Adios.
*** Azimuth ***

 Adesso però rimettiti la parrucca ed il naso rosso e torna al lavoro.
Basta nell'andare sul personale....
-- 
Luc.

 genere.
Io credo proprio di si' e te l'ho anche ampiamente dimostrato.


> Io credo proprio di si' e te l'ho anche ampiamente dimostrato.
C'e' chi sorriderebbe alle affermazioni che hai fatto.
Io invece mi sganascio solo. :-D
*** Azimuth ***

 C'e' chi sorriderebbe alle affermazioni che hai fatto.
Sorridi pure, l'importante e' che hai capito dove hai toppato.


 direi che i tuoi test sulle performance me li hanno dissolti: è meglio il
C/C++, decisamente.
I test sulle performance della tua amichetta non dimostrano assolutamente
NULLA di quanto ella voglia dimostrare. E' proprio vero: i troll non
arrivano mai da soli ;)


> Sorridi pure, l'importante e' che hai capito dove hai toppato.
si un errore lo ha fatto sicuramente..
ha perso tempo con te
:))

 arrivano mai da soli ;)
non sei da solo ??
chi è il tuo amico troll?
tienici informati...

 tienici informati...
pimpino, non rispondere alle sue provocazioni!!! Cosi facendo andrà in 
muffa, vedrai!
-- 
Luc.

 muffa, vedrai!
ma son curioso :))
chissà chi è il suo amico troll ? :P
ciao :)))

 chissà chi è il suo amico troll ? :P
Ma va che lo sai ! mi ha detto che stanotte con lui sei stato fantastico
!... furbacchione...


 si un errore lo ha fatto sicuramente..
Bravo ! l'hai ammesso !
Visto ? una cosa da te l'ho imparata il "Cut what I like" & Paste


 permetterti solo di "limare gli spigoli".
io non sono un espero di progettazione, pero` se per ottimizzare il 
codice e` necessario rivedere il desgin significa che il design era 
sbagliato. Nel caso tipico il 90% del tempo sara` impiegato da n 
funzioni (o classi) con n abbastanza piccolo: per ottimizzare ti limiti 
a scrivere quelle n funzioni in C, senza modificare il resto del codice: 
uno dei pregi di python e` che puoi richiamare direttamente codice 
scritto in C (o anche altri linguaggi) senza che faccia differenza 
rispetto al codice scritto direttamente in python.


 a scrivere quelle n funzioni in C, senza modificare il resto del codice:
Non e' affatto vero: trascuri quello che si chiama "effetto molteplicita'":
se una routine impiega, ad esempio, 10 ms ad essere eseguita, ed il tempo
medio di tutte e' di 7 ms, sembra, APPARENTEMENTE, che non vi siano routine
da ottimizzare. D'altra parte, se quella routine viene eseguita 10.000
volte, il tempo complessivo di esecuzione e' di 10.000 * 10 = 100.000 ms =
100 s!!! Ora, puoi cercare di migliorare quella singola routine (ma 10 ms e'
gia' poco!!!), oppure ripensare l'algoritmo affinche non si debbano fare
10.000 chiamate.
*** Azimuth ***

 esecuzione e' di 10.000 * 10 = 100.000 ms = 100 s!!! 
scusa, ma questo me lo dice il profiler: lancio il programma e guardo in 
quali punti esso impiega la maggior parte del tempo: nel caso d'esempio 
e` il profiler stesso a dirmi che la rountine X impiega 100 s!


 e` il profiler stesso a dirmi che la rountine X impiega 100 s!
No, il profiler ti dice che X impiega 10 ms. Il problema e' che X viene
chiamata 10.000 volte!!!
Ciao!
*** Azimuth ***

 Ho avuto accesso a tutorial gratuiti e molto ben fatti.
Una guida cartacea per me e` il top. Oltre al fatto che molti tutorial
sono scritti con i piedi (magari non e` il caso dei tuoi) oppure fanno
affermazioni piuttosto discutibili, a volte pongono come esempio anche
del codice fatto male. Mi fido poco dei tutorial quando ho da imparare
un linguaggio di programmazione vasto e complesso come il C++.
Ci sono anche dei libri gratis (sia di C++ che di Python) in rete.
Se non sbaglio oltre a Thinking in C++, Eckel ha anche scritto
Thinking in Python.
Maurizio
P.S. Questa discussione comincia ad avvicinarsi nuovamente ad un
flame come ce ne sono tanti purtroppo ultimamente in questo newsgroup.
Spero proprio che non sia cosi`.

:: Ti faccio, pero', una domanda: perche' devo investire N giorni per 
:: imparare un linguaggio con cui posso realizzare dei programmi che vanno 
:: ad una data
: Wow. Io aggiungo che con 3*N + 2 giorni potresti imparare l'assembly del 
: tuo processore per bene, tanto da riuscire ad ottimizzare i tuoi 
: programmi meglio di quanto farebbe un compilatore C/C++ qualunque. In 
: questo modo i tuoi programmi avrebbero tempi di esecuzione ancora 
: inferiori. Perche` perdi tempo con il C/C++? :)
Bah, io ho imparato l'assembly in un paio di settimane... L'Unica cosa che 
ho trovato difficile da digerire fu il discorso del segment:offset... 
comunque, ritengo che il ragionamento di Azimuth non faccia una grinza... 
insomma, bisogna vedere cosa si ottiene con l'investimento di tempo (che è 
anche denaro, quello che rende di più...).
: Non conosco Python, ma a quanto ho capito e` possibile scrivere alcune 
: routine critiche in altri linguaggi, pertanto basterebbe riscriverle.
Se ho capito il problema di azimuth, il fatto è che devo studiare due 
linguaggi!
 
: Una guida cartacea per me e` il top. Oltre al fatto che molti tutorial
Ragazzi, siete abituati male... io ho iniziato con il manuale del mio 
assemblatore! :)
Fed.

 Thinking in Python.
Perň, se l'obbiettivo di TIC++ č il C++, quello di TIPython non
č il linguaggio, ma la spiegazione di pattern con un linguaggio
semplice e potente. E la scelta č stata Python.
"So Thinking in Python is, initially, a translation of Thinking
in Patterns with Java, rather than an introduction to Python
(there are already plenty of fine introductions to that superb
language). I find this prospect to be much more exciting than
the idea of struggling through another language tutorial (my
apologies to those who were hoping for that)."
          Bruce Eckel - Prefazione di Thinking in Python
--
Gerolamo

 Thinking in Python.
Come ti e' stato fatto notare, TiP non e' un tutorial del linguaggio.
*** Azimuth ***

 Questo vale anche per i testi cartacei.
Ti do' ragione, pero' c'e' un fattore di cui devi tenere conto: scrivere un
tutorial e pubblicarlo sul web non costa nulla, se non il tempo passato a
scrivere il tutorial.
Scrivere un libro e stamparlo costa tanti ordini di grandezza di soldi in
piu', ed il risultato deve quasi per forza essere di qualita', altrimenti
nessuno ci fa soldi sopra (ed i libri si stampano per fare soldi). Questo
non garantisce che i libri siano sempre buoni, ma che i libri (in media)
tendono ad essere migliori dei tutorial in rete (in media).
Saluti,
Lanugo of the Wandering Souls

 tendono ad essere migliori dei tutorial in rete (in media).
La media e' quella cosa per cui se io mangio due polli e tu stai a digiuno,
abbiamo mangiato un pollo per uno. <g>
*** Azimuth ***

 abbiamo mangiato un pollo per uno. <g>
Questa e` bellissima :)))
La rivendero` il prima possibile. :)
Maurizio

 Dici? Secondo me i libri ce li hanno anche loro.
Anche secondo me.


 La rivendero` il prima possibile. :)
;-)))
Ti e' andata bene che non l'ho brevettata... ;-)
*** Azimuth ***

 tesi sono corrette... ;-)
Ho conosciuto persone molto capaci che leggono libri.
Sicuramente meno note e/o bravi dei vari Kernighan, Pike, ecc...
probabilmente poi i miei giudizi su tali persone non sono neanche cosi`
rilevanti.
Mi sembra assurdo comunque voler tentare di paragonare l'efficacia di un
libro con quella di un tutorial...
Maurizio

 abbiamo mangiato un pollo per uno. <g>
Esattamente. Se leggi, infatti ho scritto che questo non garantisce che i
libri siano sempre buoni, e che i tutorial in rete fanno tutti schifo. Anzi,
ti diro': quando mi misi in testa di realizzare un cubo rotante in
wireframe, mi spulciai tutti i tutorial che riuscii a trovare in rete
sull'argomento, e rimasi stupito dall'ottima qualita' di alcuni di essi.
Saluti,
Lanugo

 libro con quella di un tutorial...
Infatti il tutorial e', di norma, meglio, e anche perche' molti libri si
configurano come tutorial (anche se "mascherati" da guide di riferimento).
Ciao!
*** Azimuth ***

 sull'argomento, e rimasi stupito dall'ottima qualita' di alcuni di essi.
Ecco. Questo tanto per dirti che non servono libri per imparare a
programmare.
Ciao.
*** Azimuth ***

 programmare.
Non serve neanche un computer, per imparare a programmare, volendo mettere i
puntini sulle i.
A parte questo, avrei capito punto o nulla dei vari tutorial se non fossi
gia' stato in grado di programmare prima (anche perche' i detti tutorial non
insegnavano a programmare, ma insegnavano solo un po' di geometria e come
proiettare su 2 dimensioni uno spazio 3d, penso che non ci fosse nemmeno una
linea di codice).
Saluti,
Lanugo

 studiare subito il C/C++!
ti dimentichi di una variabile molto importante: il tempo di sviluppo.
Python consente di essere *molto* piu` produttivi: quindi gli N giorni 
spesi per imparare python saranno ripagati ampiamente dal risparmio sui 
tempi di sviluppo.
Una sola nota: dici che per imparare il C++ e` necessario il triplo di 
tempo che non ad imparare python: IMHO il C++ e` "leggermente" un po' 
piu` complesso e per padroneggiarlo e` necessario *molto* piu` tempo; 
incidentalmente il C++ e` un linguaggio che se non padroneggiato rischia 
di diventare piu` d'intralcio che d'aiuto; personalmente ho dedicato gli 
ultimi 2 anni e mezzo ad imparare il C++ *bene*, mentre per imparare 
python ho impiegato 1 mese.


 chiamata 10.000 volte!!!
scusa, ma che cavolo di profiler usi?
Tanto per fare un esempio con il C, usando gprof sotto linux; questo e` 
il file prova.c:
#include <time.h>
// aspetta un secondo
int foo()
{
  clock_t begin = clock();
  while(clock() - begin < CLOCKS_PER_SEC)
    ;
}
// aspetta un secondo
int bar()
{
  clock_t begin = clock();
  while(clock() - begin < CLOCKS_PER_SEC)
    ;
}
int main()
{
  int i;
  foo();
  for(i=0; i<10; i++)
    bar();
}
Ovviamente ci aspettiamo che bar() consumi la maggior parte del tempo di 
esecuzione. Ecco cosa ci dive gprof:
Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total
 time   seconds   seconds    calls  us/call  us/call  name
 92.31      0.36     0.36       10 36000.00 36000.00  bar
  7.69      0.39     0.03        1 30000.00 30000.00  foo
Guarda caso ci dice proprio che il 92% del tempo e` speso in bar. Quindi 
*sappiamo* dove ottimizzare.


 python ho impiegato 1 mese.
Bene come il C++? E ci fai le stesse cose?
*** Azimuth ***

 *sappiamo* dove ottimizzare.
Ecco: adesso ottimizza senza toccare main() o foo().
Ovviamente, NON VALE diminuire il numero di volte che confronti
CLOCK_PER_SECS...
*** Azimuth ***

 configurano come tutorial (anche se "mascherati" da guide di riferimento).
Io sono testardo. Noto che anche te lo sei. Quindi chiudiamola con questi
discorsi sui libri.
Te continua a studiare sui tutorial. Io continuero` a studiare come ho
sempre fatto fino ad oggi.
Maurizio

 filtri.
Programmazione nella pratica e` tradotto abbastanza bene, anche se il 
traduttore non conosceva il C++: ha tradotto "namespaces" con 
"spaziature all'interno dei nomi"...
Ma, a pensarci bene, a che ci serve leggere "Programmazione nella 
pratica"? In rete ci sono decine di tutorial *decisamente* migliori che 
non quell'accozzaglia di parole scritta da due infini personaggi in 
cerca di soldi quali Kernighan e Pike, no? ;-)
E a ben pensarci, cosa me ne faccio di tutti i libri dei vari Meyers, 
Sutter, Alexandrescu, Sedgewick, Stroustrup, Tanenbaum, 
Cormen/Leiserson/Rivest, Gamma et al., e compagnia bella?
Ah, se solo avessi scoperto prima i tutorial in rete! ;-)


Ah, se solo avessi scoperto prima i tutorial in rete! ;-)
:)
--
Rhymes (
rhymes_...@myself.com
)
http://www26.brinkster.com/rhymes
http://bw-crema.blogspot.com

 ?
C/L/R hanno fatto un fantastico libro di algoritmi "Introduzione agli
algoritmi", dal titolo ironico a giudicare dalla dimensione del volume :)
Gamma et al., Design Pattern.
Chiaramente in rete trovi tutorial molto meglio di questi libri.
Maurizio

Chiaramente in rete trovi tutorial molto meglio di questi libri.
Davvero?


Azimuth wrote:

forse dopo un mese no, ma dopo tre ora posso essere abbastanza sicuro di 
conoscere il python tanto bene quanto il C++.
Pero` e` indubbio che *non* ci faccio le stesse cose: il C++ e` talmente 
vasto che ho speso 2 anni e mezzo per padroneggiare linguaggio + 
libreria standard, senza considerare minimamente librerie di terze 
parti: quindi in C++ niente GUI ne` accesso alla rete, ad esempio.
Python e` sicuramente piu` usabile, nel senso che permette sin da subito 
di scrivere applicazioni "pratiche" e portabili: tanto per fare un 
esempio avevo bisogno di una GUI per controllare da remoto un altro PC 
(niente di speciale: solo operazioni del tipo "connettiti ad internet", 
"disconnettiti", "spegniti"); in python in un pomeriggio ho scritto sia 
il server che il client grafico; quest'ultimo gira tranquillamente 
*senza modifiche* sia su windows che su linux. Obiettivamente in C++ 
avrei impiegato molto piu` tempo (probabilmente qualche giorno, che si 
traduce in 300-400 % di tempo in piu`).
Da notare anche che avevo impiegato un pomeriggio perche` non conscevo 
ancora bene python: probabilmente se dovessi riscriverlo adesso ci 
metterei la meta` del tempo.


>Cormen/Leiserson/Rivest, Gamma et al., e compagnia bella?
Cormen/Leiserson/Rivest hanno scritto "Introduzione agli algoritmi", che 
e` un librone pauroso molto approfondito (non oso pensare ad un 
eventuale "Algoritmi avanzati" :-). Tra l'altro Rivest e` la "R" di RSA.
Gamma/Helm/Johnson/Vlissides hanno scritto "Design Patterns", che IMHO 
non dovrebbe mancare alla biblioteca di un programmatore: e` stato il 
libro da cui e` scaturito tutto il movimento dei pattern.


libro da cui e` scaturito tutto il movimento dei pattern.
Capito


 l'esame di algortimi
io ho letto la prima decina di capitoli, ma adesso l'ho messo un attimo 
da parte per leggere il Python Cookbook e successivamente More 
Exceptional C++.
Il libro e` *molto* completo (anche se non al livello di Knuth, IMHO): 
tratta gli algoritmi ad un livello di dettaglio tale da renderlo quasi 
"ultra-universitario", nel senso che molte nozioni non saranno trattate 
nel normale curriculum di una laurea triennale (per la specialistica non 
so quali siano i programmi quindi non mi pronuncio); in ogni caso 
immagino che per il tuo esame di algoritmi non sara` necessario questo 
libro, ma bastera` molto meno.


libro, ma bastera` molto meno.
Gią, infatti il libro di testo esiste gią, a cui probabilmente
affiancherņ "Algoritmi in C" di Sedgewick
