Integrare codice C in java o no?

[toto]

Salve a tutti, per la tesi di laurea (non in informatica) devo sviluppare un
modello matematico.
Il C e' piu' performante di Java per calcoli matematici, vero?
Io di C conosco veramente pochissimo e volevo sapere:
posso integrare del codice in c in un programma java (cioe', java si occupa
della connessione a db, e visualizzazione gui, i calcoli li fa il C )
In questo caso, ovviamente si perde in termini di prestazioni che scrivendo
in puro C (credo)....ma tanto da vanificare il fatto che l'algoritmo sia
scritto in C?
Grazie mille per i consigli!!!!

[Jack]

Post by toto
Salve a tutti, per la tesi di laurea (non in informatica) devo sviluppare un
modello matematico.
Il C e' piu' performante di Java per calcoli matematici, vero?
posso integrare del codice in c in un programma java (cioe', java si occupa
della connessione a db, e visualizzazione gui, i calcoli li fa il C )
In questo caso, ovviamente si perde in termini di prestazioni che scrivendo
in puro C (credo)....ma tanto da vanificare il fatto che l'algoritmo sia
scritto in C?
Grazie mille per i consigli!!!!

Mmhh, io per l'universita' avevo fatto uno studio sugli algortimi di
sort, in java e in C. Java perdeva, a dipendenza dell'algoritmo, dallo
0 al 5 % di prestazioni risp allo stesso algoritmo scritto in C. Che
per un algortimo che dura 30 secondi non ti accorgi neanche, ma se
dura 2-3 giorni...beh, le cose cambiano...

Java ha quasi le stesse prestazioni di C e C++ se lo usi in modalita'
autistica, cioe' senza interazioni con l'esterno, cioe' niente GUI, I/
O su periferiche (disco, stampante, HID, ecc.)

Cmq se vuoi interfacciare roba scritta in C con Java non ci sono
problemi, usa JNI (Java Native Interface), ti rimando al sito della
Sun java.sun.com per tutorial, spiegazioni, esempi, ecc.

[toto]

Post by Jack

Post by toto
Salve a tutti, per la tesi di laurea (non in informatica) devo sviluppare un
modello matematico.
Il C e' piu' performante di Java per calcoli matematici, vero?
posso integrare del codice in c in un programma java (cioe', java si occupa
della connessione a db, e visualizzazione gui, i calcoli li fa il C )
In questo caso, ovviamente si perde in termini di prestazioni che scrivendo
in puro C (credo)....ma tanto da vanificare il fatto che l'algoritmo sia
scritto in C?
Grazie mille per i consigli!!!!

Mmhh, io per l'universita' avevo fatto uno studio sugli algortimi di
sort, in java e in C. Java perdeva, a dipendenza dell'algoritmo, dallo
0 al 5 % di prestazioni risp allo stesso algoritmo scritto in C. Che
per un algortimo che dura 30 secondi non ti accorgi neanche, ma se
dura 2-3 giorni...beh, le cose cambiano...
Java ha quasi le stesse prestazioni di C e C++ se lo usi in modalita'
autistica, cioe' senza interazioni con l'esterno, cioe' niente GUI, I/
O su periferiche (disco, stampante, HID, ecc.)

Ah, io mi aspettavo0 crolli prestazionali del 20-30 % da quanto avevo
leggiucchiato da internet...perfetto, allora credo che faro' tutto in
java...

[Gian Uberto Lauri]

J> Mmhh, io per l'universita' avevo fatto uno studio sugli algortimi
J> di sort, in java e in C. Java perdeva, a dipendenza dell'algoritmo,
J> dallo 0 al 5 % di prestazioni risp allo stesso algoritmo scritto in
J> C. Che per un algortimo che dura 30 secondi non ti accorgi neanche,
J> ma se dura 2-3 giorni...beh, le cose cambiano...

Curiosità Jack, come hai fatto le misure ?

J> Java ha quasi le stesse prestazioni di C e C++ se lo usi in
J> modalita' autistica, cioe' senza interazioni con l'esterno, cioe'
J> niente GUI, I/ O su periferiche (disco, stampante, HID, ecc.)

t> Ah, io mi aspettavo0 crolli prestazionali del 20-30 % da quanto
t> avevo leggiucchiato da internet...perfetto, allora credo che faro'
t> tutto in java...

Se Java non mette in campo il JIT compiler, se lasci statici tutti i
metodi... I tipi nativi arrivano al processore, quelli FP al
coprocessore matematico. Il compilatore C potrebbe avere il vantaggio
di riuscire a rischedulare meglio le istruzioni per il coprocessore.

Una cosa molto importante è il tempo di accesso alla memoria. Meglio
riesci ad utilizzare le cache e meglio è, quindi, potendo, tieni
ravvicinati gli accessi alla memoria.

Per i dati, utilizzando tipi numerici ed array, i due linguaggi si
equivalgono.

Un loop di calcolo in C ben scritto potrebbe riuscire a contenere
tutto il testo del loop nella cache più preziosa del processore per
lungo tempo (teoricamente, se non ci fossero cambi di contesto, fino
alla fine dell'esecuzione), mentre del codice byte compiled in Java
potrebbe avere qualche problema in più a fare lo stesso, in quanto
abbiamo il bytecode (cache dati) ed il codice che lo interpreta (cache
istruzioni).

Io farei così:

codifico quello che dovrebbe essere il loop più eseguito sia in C che
in Java, e valuterei le prestazioni con un input corposo, facendo un
certo numero di prove. A tal scopo si può utilizzare un profiler, o
volendo "perdere tempo", farsi un wrapper JNI per la getrusage().

Se si usano solo tipi nativi, va a finire che con un po' di #define
riesci ad usare lo stesso codice in C o in Java...

Sulla base dei risultati completerei il loop di calcolo.

[Jack]

Post by Gian Uberto Lauri
J> Mmhh, io per l'universita' avevo fatto uno studio sugli algortimi
J> di sort, in java e in C. Java perdeva, a dipendenza dell'algoritmo,
J> dallo 0 al 5 % di prestazioni risp allo stesso algoritmo scritto in
J> C. Che per un algortimo che dura 30 secondi non ti accorgi neanche,
J> ma se dura 2-3 giorni...beh, le cose cambiano...
Curiosità Jack, come hai fatto le misure ?

Allora:
algoritmi di sort (bubble, heap e quicksort) su array di int,
implementati allo stesso modo.
Creo l'array, lo popolo con numeri random, lo copio (cosi che tutti
gli algoritmi hanno lo stesso array di partenza) e poi faccio partire
l'algoritmo.
Per le misure niente di eclatante ho preso il tempo subito prima
dell'inizio dell'algoritmo e subito dopo (con le fz apposite).

Ho fatto diverse prove, mi pare 10 per ogni algoritmo e per ogni
lunghezza dell'array (in realta' dovevo fare una comparazione
sull'efficienza degli algoritmi di sort, io gia' che c'ero ho fatto
anche una comparazione tra Java e C). L'array da ordinare era lungo
1000, 5000, 10k, 50k, 100k, 500k, 1M, 5M e 10M (ok, ho avuto un po' di
problemi con l'ultimo, mi andava in outofmemory :P )

Ovviamente usando sempre la stessa macchina senza processi in
background che rompessero le balle (oltre a win :( )

Per Java avevo usato la 1.4.2 (non ricordo che build) e per C avevo
usato DevC++ (v. 4.9.9.2 se non erro) sotto win.

Cmq l'aveva fatta anche un mio amico la stessa cosa (con gli algoritmi
implementati da lui) e avevamo trovato risultati analoghi.

Ciao Jack

[Gian Uberto Lauri]

J> Mmhh, io per l'universita' avevo fatto uno studio sugli algortimi
J> di sort, in java e in C. Java perdeva, a dipendenza dell'algoritmo,
J> dallo 0 al 5 % di prestazioni risp allo stesso algoritmo scritto in
J> C. Che per un algortimo che dura 30 secondi non ti accorgi neanche,
J> ma se dura 2-3 giorni...beh, le cose cambiano...

Post by Gian Uberto Lauri
Curiosità Jack, come hai fatto le misure ?

J> dell'inizio dell'algoritmo e subito dopo (con le fz apposite).

Erano queste che mi interessavano... :)

[Jack]

Post by Gian Uberto Lauri

Post by Gian Uberto Lauri
Curiosità Jack, come hai fatto le misure ?

J> dell'inizio dell'algoritmo e subito dopo (con le fz apposite).
Erano queste che mi interessavano... :)

lo devo interpretare che ho fatto una cagata o meno?

Ciao Jack

[Gian Uberto Lauri]

Post by Gian Uberto Lauri

Post by Gian Uberto Lauri
Curiosità Jack, come hai fatto le misure ?

J> dell'inizio dell'algoritmo e subito dopo (con le fz apposite).

Post by Gian Uberto Lauri
Erano queste che mi interessavano... :)

J> lo devo interpretare che ho fatto una cagata o meno?

No, non hai fatto una cagata, il metodo che hai seguito mi pare valido.

// Lo aveva scelto un mio amico che ha successivamente vinto un premio
// per la migliore routine di calcolo numerico del biennio...

Visto che lo avevi fatto, mi interessava sapere come avevi misurato il
tempo.

[Enrico 'Mc Osten' Franchi]

Post by Gian Uberto Lauri
No, non hai fatto una cagata, il metodo che hai seguito mi pare valido.

Poi per confronti fra Java e C si può andare su Alioth.
<http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=java>

Le conclusioni sono in linea, ma in linea.
Nella maggior parte degli algortimi Java perde meno del 2% (e d'altra
parte siccome stiamo usando un JIT la cosa mi torna).

Semmai il discorso è che spesso e volentieri si hanno consumi di memoria
dalle 20 alle (nel caso estremo) 200 volte superiori. Per cui a seconda
dei calcoli, bisogna vedere.

Per esempio se si manipolano molte matrici grosse, il problema
computazionale sarebbe che viene usata *troppa* RAM, eventualmente
portando a paginazione e altri problemi prestazionali indiretti.

[7***@gmail.com]

Post by Enrico 'Mc Osten' Franchi
Poi per confronti fra Java e C si può andare su Alioth.
<http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=java>
Le conclusioni sono in linea, ma in linea.
Nella maggior parte degli algortimi Java perde meno del 2% (e d'altra
parte siccome stiamo usando un JIT la cosa mi torna).

Guarda che i numeri riportati in quel benchmark non sono percentuali.
I risultati non sono tanto buoni per Java:
in 14 test su 19 Java impiega oltre il 50% del tempo in piu' rispetto
al C.

Per quanto riguarda la memoria sono d'accordo con te, ma c'e' da
considerare che con il GC di mezzo e' difficile dire quale sia la
quantita' di memoria effettiva utilizzata in piu' dal programma Java.

Saluti,
The Librarian

[Enrico 'Mc Osten' Franchi]

Post by 7***@gmail.com
Guarda che i numeri riportati in quel benchmark non sono percentuali.
in 14 test su 19 Java impiega oltre il 50% del tempo in piu' rispetto
al C.

Hai maledettamente ragione. Effettivamente mi sembravano davvero passi
da gigante anche considerando la qualità del JIT.

Post by 7***@gmail.com
Per quanto riguarda la memoria sono d'accordo con te, ma c'e' da
considerare che con il GC di mezzo e' difficile dire quale sia la
quantita' di memoria effettiva utilizzata in piu' dal programma Java.

Certamente. Il fatto è che la prevedibilità del consumo è una cosa
chiave quando la quantità di RAM è critica. Tutto qui :)

[P51D]

...Java ha quasi le stesse prestazioni di C e C++ se lo usi in modalita'
autistica, cioe' senza interazioni con l'esterno, cioe' niente GUI, I/
O su periferiche (disco, stampante, HID, ecc.)...

approfitto per fare una domanda visto che l'argomento interessa anche a me:
se devo processare un array (o buffer), in sequenza, in C incremento il
puntatore con "ptr++", e poi accedo agli elementi con "*ptr". In Java sono
costretto ad indicizzare ogni elemento "ptr[indice]", ed incrementare l'indice.
Esiste qualcosa di piu' efficiente in Java?

[Jack]

Post by P51D

...Java ha quasi le stesse prestazioni di C e C++ se lo usi in modalita'
autistica, cioe' senza interazioni con l'esterno, cioe' niente GUI, I/
O su periferiche (disco, stampante, HID, ecc.)...

se devo processare un array (o buffer), in sequenza, in C incremento il
puntatore con "ptr++", e poi accedo agli elementi con "*ptr". In Java sono
costretto ad indicizzare ogni elemento "ptr[indice]", ed incrementare l'indice.
Esiste qualcosa di piu' efficiente in Java?

In C per il compilatore usare i puntatori per un array o usare la
notazione array[indice] e' uguale, quando trasforma in assembler
scrive la stessa cosa.

In Java usare array[indice] e' AFAIK il metodo piu' efficiente.

Ciao Jack

[P51D]

Post by Jack
In C per il compilatore usare i puntatori per un array o usare la
notazione array[indice] e' uguale, quando trasforma in assembler
scrive la stessa cosa.

No, come può essere!
Capisco che un array in C è un puntatore, ma in C, scrivere "array[indice]"
implica comunque la somma dell'indice sul puntatore dell'array.
Mentre io intendevo l'incremento di un puntatore.

[Jack]

Post by P51D

Post by Jack
In C per il compilatore usare i puntatori per un array o usare la
notazione array[indice] e' uguale, quando trasforma in assembler
scrive la stessa cosa.

No, come può essere!

puo' essere perche' il compilatore e' intelligente.

[P51D]

Post by Jack

Post by P51D

Post by Jack
In C per il compilatore usare i puntatori per un array o usare la
notazione array[indice] e' uguale, quando trasforma in assembler
scrive la stessa cosa.

No, come può essere!

puo' essere perche' il compilatore e' intelligente.

sarà pure, ma come fa prima della compilazione a sapere che l'indice è
sequenziale?
Non è una questione di intelligenza, non lo può sapere.

[Gian Uberto Lauri]

Post by Jack

Post by P51D

Post by Jack
In C per il compilatore usare i puntatori per un array o usare la
notazione array[indice] e' uguale, quando trasforma in assembler
scrive la stessa cosa.

No, come può essere!

puo' essere perche' il compilatore e' intelligente.

P> sarà pure, ma come fa prima della compilazione a sapere che
P> l'indice è sequenziale? Non è una questione di intelligenza, non
P> lo può sapere.

In realtà usa due indirizzamenti diversi se la CPU li supporta, e quindi
il peso in cicli macchina non cambia.

Credo che solo sui macchine che non supportano una forma di indirizzamnto
[indirizzo base + displacement] occorra una operazione in più.

[Enrico 'Mc Osten' Franchi]

Post by P51D
sarà pure, ma come fa prima della compilazione a sapere che l'indice è
sequenziale?
Non è una questione di intelligenza, non lo può sapere.

Potrebbe. Dipende dal codice. Il mestiere dell'ottimizzatore di un
compilatore è proprio quello di fare il pelo al problema della
terminazione, cercando di scoprire quante più possibile informazioni e
usandole per ottimizzare.

[Gian Uberto Lauri]

J> In C per il compilatore usare i puntatori per un array o usare la
J> notazione array[indice] e' uguale, quando trasforma in assembler
J> scrive la stessa cosa.

Sicuro ? Sei proprio certo che *var non venga tradotto usando un
indirizzamento "secco" e var[i] un indirizzamento con displacement ?

Poi a runtime dovrebbero essercis pochi problemi di prestazioni...

J> In Java usare array[indice] e' AFAIK il metodo piu' efficiente.

AFAIK l'unico.

[Jack]

Post by Gian Uberto Lauri
J> In C per il compilatore usare i puntatori per un array o usare la
J> notazione array[indice] e' uguale, quando trasforma in assembler
J> scrive la stessa cosa.
Sicuro ? Sei proprio certo che *var non venga tradotto usando un
indirizzamento "secco" e var[i] un indirizzamento con displacement ?

mmhh no sicuro sicuro non lo sono. Sinceramente sono convinto dipenda
dal compilatore e da cosa c'e' intorno alla chiamata.
Per dire e' diverso se accedo ad un array cosi a[5] oppure se ci
accedo cosi a[indice] all'interno di un loop (penso).

In linea di principio se il compilatore e' "smart" abbastanza riesce a
ottimizzare il codice e quindi le due cose sono equivalenti, altrimeni
usare i puntatori e' piu' efficiente (il compilatore non deve far
nulla)

Ad esempio se si fa un loop (in C) cosi:

for(i=0;i<12;i++)
{
a[i] = b[i] + c[i];
}

i compilatore moderni (tipo GCC), se hanno attivato le ottimizzazioni
vettoriali (ad esempio il GCC per MacOSX, se si compila per processori
G4,G5 o Intel) questa cosa la fa diventare:

for(i=0;i<12;)
{
a[i] = b[i] + c[i];
a[i+1] = b[i+1] + c[i+1];
a[i+2] = b[i+2] + c[i+2];

i += 3; //e' un esempio, non e' che lo divide in 3
}

e il codice passa all'unita' vettoriale che processa ogni ciclo del
loop in una botta sola, e quindi farla con o senza i puntatori cambia
poco o niente.

OK, mi sa che sono andato un po' OT, cmq tutto questo per dire che con
i compilatori un po' evoluti uno puo' scrivere un po' quello che vuole
(con certi limiti eh :) ) ma poi il compilatore fa un po' quello che
vuole.

Tutto questo e' IMHO e AFAIK, se ho detto fregnacce spero che qualcuno
me lo dica.
E se qualcuno ha articoli, paper, ecc. su questo argomento saro ben
felice di leggerli :P.
(sto pensando di comprare il dragonbook)

Ciao Jack

[jRed]

Post by Jack
In linea di principio se il compilatore e' "smart" abbastanza riesce a
ottimizzare il codice e quindi le due cose sono equivalenti, altrimeni
usare i puntatori e' piu' efficiente (il compilatore non deve far
nulla)
i compilatore moderni (tipo GCC), se hanno attivato le ottimizzazioni
vettoriali (ad esempio il GCC per MacOSX, se si compila per processori
e il codice passa all'unita' vettoriale che processa ogni ciclo del
loop in una botta sola, e quindi farla con o senza i puntatori cambia
poco o niente.

Giusto una domanda, ovviamente quelle opzioni di ottimizzazioni sono
attive anche per il GCC sotto Linux...

Ora perchè mi veniva il dubbio, l'altra volta che ho ricompilato tutta
una Gentoo ci ha messo una vita, ovviamente con molte ottimizzazioni
attive e codice poco pulito il compilatore spende molto tempo
nell'ottimizzazione...e poco nella compilazione...

Chissà cosa fa GCJ a livello di ottimizzazioni! :P

Ciao,
jRed

[Gian Uberto Lauri]

j> Chissà cosa fa GCJ a livello di ottimizzazioni! :P

Potresti rimanerne deluso... L'architettura della JVM è molto diversa
da quella dei processori "tradizionali"...

[Enrico 'Mc Osten' Franchi]

Post by Gian Uberto Lauri
Potresti rimanerne deluso... L'architettura della JVM è molto diversa
da quella dei processori "tradizionali"...

In particolare è pur sempre una macchina a stack.
Ad ogni modo il discorso cambia poco. IMHO la JVM ottimizza
relativamente poco *prima* per dare più possibilità di spremere cicli al
JIT *dopo*.

Poi resta il fatto che gcj può compilare in codice nativo. In qualche
punto gli alberi astratti dei programmi nei vari linguaggi sono buttati
fuori in qualche linguaggio intermedio comune, quello è ottimizzato e
poi tramutato in asm.

Non so se si fa ancora, ma direi che potrebbe essere a livello del
three-address code.

[Gian Uberto Lauri]

Post by Gian Uberto Lauri
Potresti rimanerne deluso... L'architettura della JVM è molto
diversa da quella dei processori "tradizionali"...

E'OF> In particolare è pur sempre una macchina a stack.

Ed i processori normali NON lo sono, fa eccezione lo stack floating point
delle architetture Intel...

Inoltre non conosco molte macchine che hanno l'istruzione macchina
"invoca metodo virtuale" :)

[Enrico 'Mc Osten' Franchi]

Post by Gian Uberto Lauri
Ed i processori normali NON lo sono, fa eccezione lo stack floating point
delle architetture Intel...

Dopo tutto il principale vantaggio di un set di istruzioni a stack è che
i binari sono più piccoli. Ma perdi in performance (e riesci ad emulare
abbastanza facilmente una macchina a stack con una a registri).

Per la parte floating point delle architetture Intel non me ne parlare.
Riesco a pensare a poche cose più dementi di avere registri da 80bit
quando in memoria i double sono a 64 bit, con il risultato che in
pratica il risultato di una sequenza di operazioni è in buona sostanza
dipendente da quello che sta succedendo sulla macchina (e che la stessa
'funzione' eseguita due volte può dare risultati diversi).

[Gian Uberto Lauri]

E'OF> Dopo tutto il principale vantaggio di un set di istruzioni a
E'OF> stack è che i binari sono più piccoli.

Credo sia uno dei motivi per cui la hanno scelta come architettura...

E'OF> Per la parte floating point delle architetture Intel non me ne
E'OF> parlare. Riesco a pensare a poche cose più dementi di avere
E'OF> registri da 80bit quando in memoria i double sono a 64 bit

Scusa, ma i registri MMX dove è che stanno adesso ? Una volta c'era una
istuzione da 100 cicli relativa all'attivazione di quei registri...

[Enrico 'Mc Osten' Franchi]

Post by Gian Uberto Lauri
Scusa, ma i registri MMX dove è che stanno adesso ? Una volta c'era una
istuzione da 100 cicli relativa all'attivazione di quei registri...

Uh, non seguo le n-mila estensioni ASM ad x86 :P

Scherzi a parte, non parlo dei registri MMX. Quelli sono 64bit precisi
(anche se IIRC mi pare che almeno una volta fossero solo un modo diverso
di accedere allo stack FPU).

Inoltre i registri MMX hanno un interfaccia per calcoli *vettoriali
interi*, non floating point (con la genialata allegata che se devi
mischiare le istruzioni SIMD *e* istruzioni floating point devi romperti
le palle non da poco, per cui... si aggiungono SSE).

Se uno invece guarda il semplice e potentissimo progetto di AltiVec, gli
viene una lacrimuccia. E pensa, io sono un softwarista puro. Non oso
pensare cosa capiti ad un esteta dell'hardware o a un vero asm-hacker.

[Gian Uberto Lauri]

E'OF> Scherzi a parte, non parlo dei registri MMX. Quelli sono 64bit
E'OF> precisi (anche se IIRC mi pare che almeno una volta fossero solo
E'OF> un modo diverso di accedere allo stack FPU).

Almeno una volta era esattamente così, e 100 cicli macchina per passare
da un modo all'altro.

E'OF> Inoltre i registri MMX hanno un interfaccia per calcoli
E'OF> *vettoriali interi*

Oh, ora lo chiamano vettoriale. Olim era solo parallelismo SIMD
(Single Instruction Multiple Data)

[Enrico 'Mc Osten' Franchi]

Post by Gian Uberto Lauri
E'OF> Inoltre i registri MMX hanno un interfaccia per calcoli
E'OF> *vettoriali interi*
Oh, ora lo chiamano vettoriale. Olim era solo parallelismo SIMD
(Single Instruction Multiple Data)

No. Sono io che *impropriamente* lo chiamo 'vettoriale'.

[Enrico 'Henryx' Bianchi]

Post by jRed
Chissà cosa fa GCJ a livello di ottimizzazioni! :P

Da quel poco che ho visto, piu` che di una compilazione a codice nativo,
il GCJ non fa altro che eseguire un wrapper dell'applicativo tale da
renderlo eseguibile senza alcuna VM[1]

Enrico
[1] non proprio vero, in quanto lega all'eseguibile una libreria che fa
le veci della VM

[Enrico 'Mc Osten' Franchi]

Post by Gian Uberto Lauri
Sicuro ? Sei proprio certo che *var non venga tradotto usando un
indirizzamento "secco" e var[i] un indirizzamento con displacement ?

Agli occhi del compilatore una scrittura del tipo

*(p + i) e p[i]

sono del tutto equivalenti (addirittura si mantiene la commutatività e
puoi scrivere i[p]). Questo è da standard.

6.5.2.1 Array subscripting

Constraints
1 One of the expressions shall have type ''pointer to object type'', the
other expression shall have integer type, and the result has type
''type''.

Semantics
A postfix expression followed by an expression in square brackets[]is a
subscripted designation of an element of an array object. The definition
of the subscript operator[] is that E1[E2]is identical to(*((E1)+(E2))).
Because of the conversion rules that apply to the binary+operator, if
E1 is an array object (equivalently, a pointer to the initial element of
an array object) and E2 is an integer, E1[E2]designates the E2-th
element of E1(counting from zero).


Poi chiaramente se i è una costante (eventualmente 0) ci possono essere
ottimizzazioni aggiuntive, ma è un altro discorso (e le ottimizzazioni
non riguardano lo standard).

[Gian Uberto Lauri]

Sicuro ? Sei proprio certo che *var non venga tradotto usando un
indirizzamento "secco" e var[i] un indirizzamento con displacement ?

E'OF> Agli occhi del compilatore una scrittura del tipo

E'OF> *(p + i) e p[i]

Questa, Enrico, e` la situazione banale, deve fare tutte due le volte
la stessa cosa.

Io pensavo alla situazione in cui si usa un puntatore k che punta
all'i-esimo valore in p[]

Qui al massimo cambia il tipo di indirizzamnto.

[Enrico 'Mc Osten' Franchi]

Post by Gian Uberto Lauri
Io pensavo alla situazione in cui si usa un puntatore k che punta
all'i-esimo valore in p[]

Credo che stiamo dicendo due cose diverse. Mi faresti un esempio?
Dici

char *k = p + i;

Ma non capisco a che livello stiamo parlando: se è a livello di quello
che fa il compilatore sotto il cappuccio o a livello di linguaggio.

[Gian Uberto Lauri]

Io pensavo alla situazione in cui si usa un puntatore k che punta
all'i-esimo valore in p[]

E'OF> Credo che stiamo dicendo due cose diverse. Mi faresti un
E'OF> esempio? Dici

E'OF> char *k = p + i;

int i;
int p[100];
int *k;

/* ... */

k=p;
for(i=0;i<100;i++) {
foo(p[i]);
bar(k++);
}

Se non erro dovrebbe risolvere ambedue gli accessi al vettore con una
istruzione sola, ma usando due tipi di indirizzamento diversi (se la
cpu li supporta)

E'OF> Uccidete i tenetevi riso e bacchette per voi.

Splendida soluzione per il problema!

[Enrico 'Mc Osten' Franchi]

Post by Gian Uberto Lauri
E'OF> char *k = p + i;
int i;
int p[100];
int *k;
/* ... */
k=p;
for(i=0;i<100;i++) {
foo(p[i]);
bar(k++);
}
Se non erro dovrebbe risolvere ambedue gli accessi al vettore con una
istruzione sola, ma usando due tipi di indirizzamento diversi (se la
cpu li supporta)

Beh, questa è tutta roba 'fuori dallo standard'. Nel senso che ogni
compilatore può fare un po' come vuole.

Comunque il sorgente:

extern void foo(int);
extern void bar(int*);

int main (int argc, char const* argv[])
{
int i;
int p[100];
int *k;

for(i= 0;i<100;i++) {
foo(p[i]);
bar(k++);
}
return 0;
}


da come asm

.text
.globl _main
_main:
pushl %ebp
movl %esp, %ebp
subl $440, %esp
movl $0, -16(%ebp)
jmp L2
L3:
movl -16(%ebp), %eax
movl -416(%ebp,%eax,4), %eax
movl %eax, (%esp)
call L_foo$stub
movl -12(%ebp), %edx
leal -12(%ebp), %eax
addl $4, (%eax)
movl %edx, (%esp)
call L_bar$stub
leal -16(%ebp), %eax
addl $1, (%eax)
L2:
cmpl $99, -16(%ebp)
jle L3
movl $0, %eax
leave
ret
.section
__IMPORT,__jump_table,symbol_stubs,self_modifying_code+pure_instructions
,5
L_foo$stub:
.indirect_symbol _foo
hlt ; hlt ; hlt ; hlt ; hlt
L_bar$stub:
.indirect_symbol _bar
hlt ; hlt ; hlt ; hlt ; hlt
.subsections_via_symbols



In particolare il primo

foo(p[i]);

diventa

movl -16(%ebp), %eax
movl -416(%ebp,%eax,4), %eax
movl %eax, (%esp)
call L_foo$stub

In particolare nota l'accesso -416(%ebp,%eax,4)

mentre

bar(k++);

diventa
movl -12(%ebp), %edx
leal -12(%ebp), %eax
addl $4, (%eax)
movl %edx, (%esp)
call L_bar$stub

Quindi direi che si, complessivamente l'accesso è diverso. Ma solo
perchè nel primo caso ho un offset variabile.

Post by Gian Uberto Lauri
E'OF> Uccidete i tenetevi riso e bacchette per voi.
Splendida soluzione per il problema!

Lo penso anche io. E non ha nemmeno l'ombra di un deadlock.

[P51D]

Post by Enrico 'Mc Osten' Franchi

Post by Gian Uberto Lauri
Sicuro ? Sei proprio certo che *var non venga tradotto usando un
indirizzamento "secco" e var[i] un indirizzamento con displacement ?

Agli occhi del compilatore una scrittura del tipo
*(p + i) e p[i]
sono del tutto equivalenti (addirittura si mantiene la commutatività e
puoi scrivere i[p]). Questo è da standard.

su questo è ok, ma io intendevo (e ho scritto) diversamente, cioè:

*(p++)

e

p[i++]

..non credo vengano compilati nello stesso modo.

[Enrico 'Mc Osten' Franchi]

Post by P51D
*(p++)
e
p[i++]
..non credo vengano compilati nello stesso modo.

Scusa, hai ragione. No, non possono essere compilati allo stesso modo,
visto che sono semanticamente diversi.

Tipicamente fra i due il valore di p cambia.

[P51D]

Post by Enrico 'Mc Osten' Franchi

Post by P51D
*(p++)
e
p[i++]
..non credo vengano compilati nello stesso modo.

Scusa, hai ragione. No, non possono essere compilati allo stesso modo,
visto che sono semanticamente diversi.

...e la cosa mi fa inca..are tantissimo in Java ma in genere nei linguaggi
cosiddetti "moderni", dove l'aritmetica dei puntatori è vista come un
attentato alla sicurezza dello Stato :-(

[Enrico 'Mc Osten' Franchi]

Post by P51D
...e la cosa mi fa inca..are tantissimo in Java ma in genere nei linguaggi
cosiddetti "moderni", dove l'aritmetica dei puntatori è vista come un
attentato alla sicurezza dello Stato :-(

Non ci vedo nulla di male, personalmente. Ci sono indubbi casi in cui i
puntatori e la gestione esplicita della memoria sono fondamentali (tipo
a breve dovrei scrivere il gestore della memoria per un interprete).

Ma nella maggior parte dei casi, sono dettagli che non servono al
programmatore (a patto di avere un linguaggio ricco a sufficienza).

Chiediamoci in una tipica applicazione quando useremmo l'aritmetica dei
puntatori. Quando veramente serve, e quando invece bastano le reference.

Non a caso anche linguaggi 'semimoderni' (secondo la tua definizione)
come potrebbero essere il C++ usano con accortezza i puntatori,
preferendo quando possibile i reference (che non hanno aritmetica). Ma
non solo: ci sono fiori di classi (auto_ptr nella libreria standard e
qualcosa ancora di meglio in boost, pare si chiami checked_ptr IIRC) che
cercano di arginare i problemi della gestione esplicita della memoria.

L'altra cosa che stiamo scrivendo è per l'appunto un sistema che
staticamente va a beccare gli accessi out of bound sulle stringhe (fra
le varie cose). Perchè? Perchè è un errore tipico.

Il punto è che quando ci si rende conto che una feature di un linguaggio
di 35 anni fa, pensato per l'efficienza e pensato per essere quanto più
vicino alla macchina senza scegliere in dettagli, causa la maggior parte
dei bachi, viene da chiedersi se il gioco valga la candela.

Oggi l'efficienza non è così importante (non in tutti i casi, e spesso
basta ottimizzare le parti critiche). I programmi sono ancora più
complessi e tutto... bene, è il tempo di usare qualcosa di più vicino al
programmatore.

Pensa che per me Java è fin troppo di basso livello per molte cose. Ma
non disdegno mica il C (tempo fa avevo fatto una libreria per la
manipolazione di polinomi su anelli modulo n che doveva essere parecchio
efficiente, visto che seriviva per problemi di teoria dei numeri). Ecco.
Li C, C e ancora C. La memoria la devo gestire io, e devo gestirla nel
modo più efficiente possibile: devo essere ragionevolmente certo che
dentro un loop veloce non mi allochi e deallochi memoria. Devo accettare
ridondanza di memoria negli oggetti costruiti (poichè lavorando con
interi di dimensione arbitraria posso avere *sempre* bisogno di
ingrandirmi), e quindi diventa vitale che un oggetto appena non serve
sia distrutto.

Puntatori e sporchevolezze a gogo, roba tipo

typedef struct {
size_t degree;
size_t _allocated;
mpz_t mod;
BOOL _constructed;
mpz_t *coefs;
} __aks_poly_struct;

typedef __aks_poly_struct ap_t[1];

(questo è codice vero dalla libreria), per evitarsi un sacco di malloc
(tipicamente in questo modo almeno la struct finisce sullo stack, ma la
si passa in giro senza copiarla)

[Gian Uberto Lauri]

Post by P51D
...e la cosa mi fa inca..are tantissimo in Java ma in genere nei
linguaggi cosiddetti "moderni", dove l'aritmetica dei puntatori è
vista come un attentato alla sicurezza dello Stato :-(

E'OF> Non ci vedo nulla di male, personalmente.

Con le opportune premesse.

E'OF> Il punto è che quando ci si rende conto che una feature di un
E'OF> linguaggio di 35 anni fa, pensato per l'efficienza e pensato per
E'OF> essere quanto più vicino alla macchina senza scegliere in
E'OF> dettagli, causa la maggior parte dei bachi, viene da chiedersi
E'OF> se il gioco valga la candela.

Non sono gli anni che fanno superato un progetto software. Anzi, tanto
di cappello a progetti che hanno 30 e più anni di vita.

Più che altro, è calata la qualità media dei programmatori rispetto a
quando è stato fatto il progetto. C richiede buoni programmatori,
buoni secondo gli standard di quando è stato scritto.

E'OF> Oggi l'efficienza non è così importante

Non totalmente sono d'accordo. Qualche giorno fa Caterpillar ha
lanciato la campagna "mi illumino di meno". Mi ha fatto pensare alla
quantità di energia che viene usata in software poco efficente. Ci
sono in giro computer che assorbono 6 kW, e non sono particolarmente
grossi come server, mi piacerebbe vedere se il costo per ciclo
macchina è ancora irrisorio.

E'OF> e spesso basta ottimizzare le parti critiche.

Questo è invece oggettivo.

[Enrico 'Mc Osten' Franchi]

Post by Gian Uberto Lauri
Non sono gli anni che fanno superato un progetto software. Anzi, tanto
di cappello a progetti che hanno 30 e più anni di vita.

No. Ma gli anni cambiano le condizioni al contorno. Una volta qualunque
persona ti avrebbe detto che il tempo macchina costava più del tempo
uomo. Oggi è vero il contrario.

Post by Gian Uberto Lauri
Più che altro, è calata la qualità media dei programmatori rispetto a
quando è stato fatto il progetto. C richiede buoni programmatori,
buoni secondo gli standard di quando è stato scritto.

I bachi di cui stiamo parlando sono talmente diffusi che verrebbe da
chiedersi se esistono davvero dei 'buoni programmatori'. IMHO più
semplicemente i buoni programmatori fanno pure loro fior di errori, e
più è complesso il progetto software e più è facile introdurne.

Inoltre non è la qualità media che influenza queste cose. Ci sono fior
di ambiti dove comunque lavora solo l'elite (pensa per esempio ad un
compilatore, librerie di sistema, di rete, ma anche applicazioni mission
critical). Se avviene una rapita riproduzione fra i programmatori di un
noto ambiente (homo visualbasicensis) senza skill, il loro aumento
abbassa la qualità media, ma non va ad intaccare quella di quelli che
fanno la roba di cui sopra.

La qualità media è forse anche scesa, ma questo non è certo il problema
che fa si che ci siano fior di bachi in tutti i tipi di software.

Scrivere in C è più costoso. Ci va più tempo per debuggare, più tempo
per progettare le cose per bene. Anche i costi di deployment per molte
categorie software sono più costosi.

Post by Gian Uberto Lauri
E'OF> Oggi l'efficienza non è così importante
Non totalmente sono d'accordo. Qualche giorno fa Caterpillar ha
lanciato la campagna "mi illumino di meno". Mi ha fatto pensare alla
quantità di energia che viene usata in software poco efficente. Ci
sono in giro computer che assorbono 6 kW, e non sono particolarmente
grossi come server, mi piacerebbe vedere se il costo per ciclo
macchina è ancora irrisorio.

Il punto è che la maggior parte dei software per gran parte del tempo,
fanno poco o nulla. Questo è quanto vale per sostanzialmente tutti i
software desktop (e quelli che hanno bisogno di alte performance *sono*
scritti almeno in parte in C/C++).

Per il software di rete spesso il tempo computazionale è piccolo
rispetto al tempo per fare query su un db (e quello si che è scritto in
C/C++, anche se mi pare che di recente sia venuto su bene hsql db, in
Java apputno) e al tempo di risposta (per cui dal punto di vista
dell'efficienza si tendono ad abbandonare i CGI -- e perfino un
merdosissimo sw in PHP ha in generale performance sotto carico di un CGI
in C).

Ci sono come vedi vaste classi di sw in cui l'efficienza *davvero* non è
importante. Perchè vuoi per colli di bottiglia, vuoi per altri motivi,
le carte in tavola non contano.


Poi possiamo ragionare anche su un paio di cose. OCaml dal punto di
vista dell'efficienza se la gioca con il C. Dal punto di vista del
programmatore è invece un linguaggio di livello piuttosto alto, con cui
è *davvero* veloce sviluppare. Eppure... quanti lo usano?

[Gian Uberto Lauri]

Più che altro, è calata la qualità media dei programmatori rispetto
a quando è stato fatto il progetto. C richiede buoni programmatori,
buoni secondo gli standard di quando è stato scritto.

E'OF> I bachi di cui stiamo parlando sono talmente diffusi che
E'OF> verrebbe da chiedersi se esistono davvero dei 'buoni
E'OF> programmatori'. IMHO più semplicemente i buoni programmatori
E'OF> fanno pure loro fior di errori, e più è complesso il progetto
E'OF> software e più è facile introdurne.

Esistono, ho avuto occasione di vederli, qualcosa di paragonabile
all'illuminazione zen :).

Conta che una volta valeva la pena di ragionarci su sul codice prima
di darlo in pasto al compilatore ed al debugger, vuoi per i tempi di
esecuzione vuoi per l'uso delle risorse. Quindi si andava molto più
attenti.

E'OF> Inoltre non è la qualità media che influenza queste cose. Ci
E'OF> sono fior di ambiti dove comunque lavora solo l'elite (pensa per
E'OF> esempio ad un compilatore, librerie di sistema, di rete, ma
E'OF> anche applicazioni mission critical).

Qui potrei raccontarti qualcosina di divertente che include il
software di navigazione di un certo vettore...

E'OF> riproduzione fra i programmatori di un noto ambiente (homo
E'OF> visualbasicensis) senza skill, il loro aumento abbassa la
E'OF> qualità media, ma non va ad intaccare quella di quelli che fanno
E'OF> la roba di cui sopra.

Vero. Ma essendo molti ed economici ci saranno manager che affideranno
progetti a homini visualbasicensis invece che a programmatori di
adatta capacità (ma maggiore costo).

E'OF> La qualità media è forse anche scesa, ma questo non è certo il
E'OF> problema che fa si che ci siano fior di bachi in tutti i tipi di
E'OF> software.

Ni.

E'OF> Scrivere in C è più costoso. Ci va più tempo per debuggare, più
E'OF> tempo per progettare le cose per bene. Anche i costi di
E'OF> deployment per molte categorie software sono più costosi.

Per le categorie mi servirebbe un esempio per capire meglio il tuo
discorso.

Per lo scrivere... Si e no. Penso dipenda dall'esperienza.

Certo, il C va bene con organizzazioni del lavoro tipo quelle ne "il
mitico mese uomo" (team di 10 persone in cui c'è un programmatore
senior, uno junior, un code lawyer e il resto supporto).

E'OF> Il punto è che la maggior parte dei software per gran parte del
E'OF> tempo, fanno poco o nulla.

Vero, ma per fare il resto mangiano un barcone di CPU :).

Io stavo pensando principalmente a codice che gira su server, anche
grossetti. Con quella mentalità venne sviluppata una applicazione che,
fintanto che stava nel laboratorio, andava benissimo. Salvo mettere in
crisi il server con qualche decina di migliaia di page fault/secondo
quando arrivava il picco d'utenza... Energia sprecata sia sul server
che sulle macchine client.

E'OF> Per il software di rete spesso il tempo computazionale è piccolo
E'OF> rispetto al tempo per fare query su un db

Anche la query va scritta con efficienza.

E'OF> Ci sono come vedi vaste classi di sw in cui l'efficienza
E'OF> *davvero* non è importante. Perchè vuoi per colli di bottiglia,
E'OF> vuoi per altri motivi, le carte in tavola non contano.

Non mi convinci del tutto. Il discorso a naso torna perché non si
stanno considerando alcune variabili.

E'OF> con cui è *davvero* veloce
E'OF> sviluppare. Eppure... quanti lo usano?

Mi puoi indicare qualcosa di veramente notevole fatto in Ocaml?

Non è per sminuire quel linguaggio. La fortuna di un linguaggio è un
discorso complesso, usualmente il linguaggio più noti hanno avuto o un
grosso impulso da parte del marketing o sono stati usati per scrivere
qualcosa di notevole (i.e. un kernel). Il Pascal non rientra in queste
categorie ma a naso era l'unico linguaggio didattico(*) valido
disponibile.

(*) Anche nei costi di compilazione/esecuzione.

[Enrico 'Mc Osten' Franchi]

Post by Gian Uberto Lauri
Esistono, ho avuto occasione di vederli, qualcosa di paragonabile
all'illuminazione zen :).

Intendo dire... programmatori che *non* sbagliano?
Voglio dire, un conto è sbagliare *poco*. Oppure sbagliare ma avere
ampie skill nello scrivere i test/verifiche formali per cui poi gli
errori vengono presi al volo. Ma *non* sbagliare proprio...

Post by Gian Uberto Lauri
Conta che una volta valeva la pena di ragionarci su sul codice prima
di darlo in pasto al compilatore ed al debugger, vuoi per i tempi di
esecuzione vuoi per l'uso delle risorse. Quindi si andava molto più
attenti.

Io a suo tempo ho iniziato così (a casa non avevo il compilatore). Ma se
è per quello io sono anche uno di quelli che pensa che il codice che uno
scrive se lo dovrebbe anche verificare per lo meno in modo semi-formale.
Sicuramente per gli algoritmi sarebbe il caso che uno si buttasse giù
almeno una prova di correttezza. Cosa relativamente diffusa nel mondo
dei linguaggi dichiarativi (dove in effetti è pure più facile da fare),
e poco in quello degli imperativi.

Post by Gian Uberto Lauri
Qui potrei raccontarti qualcosina di divertente che include il
software di navigazione di un certo vettore...

L'arianne 5? So tutto quasi a memoria. Dopo tutto il studio nel campo
delle verifiche formali statiche di software.

Post by Gian Uberto Lauri
Vero. Ma essendo molti ed economici ci saranno manager che affideranno
progetti a homini visualbasicensis invece che a programmatori di
adatta capacità (ma maggiore costo).

Non a caso il numero di 'bagni di sangue' è impressionante. Circa un
progetto su quattro giunge a compimento, secondo le ultime statistiche
che ho spulciato.

Post by Gian Uberto Lauri
Per le categorie mi servirebbe un esempio per capire meglio il tuo
discorso.

Se devi supportare più sistemi (metti qualche unix commerciale, linux,
windows) ti trovi a lavorare con gli autotools in primo luogo. In
secondo luogo devi avere le macchine suddette in casa e testare
pacchettizzazioni et similia su tutte quante le macchine (che vuole dire
magari due build system e diversi auto-installer).

Poi ci si trova a gestire le librerie esterne. Che possono essere
tipicamente presenti sul target oppure no. Nel caso bisogna vedere con
quali versioni funziona, con quali no. In sistemi dove il gcc non è il
default, vedere se la compatibilità binaria funziona o non funziona.
Oppure portare le librerie con la tua applicazione e nel caso essere
pronto a gestire possibili conflitti con le librerie sull'ospite.

A me Java non fa impazzire, ma complessivamente da questo punto di vista
è un notevole passo avanti. E pure li ci sono delle storie dell'orrore,
eh... Confesso che mi piace ancora di più Python, per queste cose.

Post by Gian Uberto Lauri
Per lo scrivere... Si e no. Penso dipenda dall'esperienza.

Ho circa 10 anni di esperienza nello scrivere C (e sono solo 10 solo
perchè sono giovane io). Eppure mi è molto più facile usare Ruby (che
conosco solo da un anno). Semplicemente C è più complesso a prescindere
da usare. E ritengo che la qualità di quello che scriva sia 'decente'
(il massimo che uno può dirsi da solo, IMHO) in ambo i casi.

Post by Gian Uberto Lauri
Certo, il C va bene con organizzazioni del lavoro tipo quelle ne "il
mitico mese uomo" (team di 10 persone in cui c'è un programmatore
senior, uno junior, un code lawyer e il resto supporto).

Dopo di che rimangono in dietro, allora aggiungono altri 10 junior e non
si fa più un accidenti del tutto :P

Post by Gian Uberto Lauri
Io stavo pensando principalmente a codice che gira su server, anche
grossetti. Con quella mentalità venne sviluppata una applicazione che,
fintanto che stava nel laboratorio, andava benissimo. Salvo mettere in
crisi il server con qualche decina di migliaia di page fault/secondo
quando arrivava il picco d'utenza... Energia sprecata sia sul server
che sulle macchine client.

Questo lo ho visto anche con una applicazione C++ che mi sono rifiutato
di debuggare ( o meglio, per la quale ho rifiutato di prendere
l'incarico di aggiustarla ). Era un'applicazione computazionale. E
leggendo brevemente il codice mi sono venuti 3 capelli bianchi.

Post by Gian Uberto Lauri
Anche la query va scritta con efficienza.

Assolutamente e soprattutto si. Ma questo prescinde se il linguaggio
client è Java, C o Python.

Post by Gian Uberto Lauri
Non mi convinci del tutto. Il discorso a naso torna perché non si
stanno considerando alcune variabili.

IMHO scegliere un linguaggio di basso livello per un progetto software
'di alto livello' (ovvero di livello applicativo) rientra nel caso della
'premature optimization', se è fatto a scopo prestazionale.

IMHO un approccio più sensato è scegliere un linguaggio che si presta al
task in questione, scrivere e poi vedere. Se le performance non sono
accettabili (per diversi valori di accettabile) si passa ad un profiler
e si riscrivono in C (o addirittura in ASM, a seconda di quello che si
sta facendo) le parti critiche.

Dopo di che, pensa ad un'applicazione web. Quanto ci mette Python (o
Java) a processare un po' di testo rispetto a quanto tempo ci va per
fare tutte le query al db per tirare fuori le informazioni.

Inoltre è stato dimostrato che utilizzare un mod_qualcosa (con il
linguaggio Qualcosa) è comunque più efficiente di usare un CGI (fosse
anche in C). Certo, chiamare in C gli internals di Apache è ancora più
veloce (ma scriversi un webserver custom 'monoapplicazione' potrebbe
essere ancora più veloce, se in mano a persone competenti).

Post by Gian Uberto Lauri
Mi puoi indicare qualcosa di veramente notevole fatto in Ocaml?

CIL. E' un bel softare, Ma a parte quello è un linguaggio usato molto in
ambiti accademici/universitari/scientifici. Per cui è difficile andare a
beccare le specifiche applicazioni (a meno che qualcosa non sia nel ramo
in cui stai lavorando studiando).

Post by Gian Uberto Lauri
Non è per sminuire quel linguaggio. La fortuna di un linguaggio è un
discorso complesso, usualmente il linguaggio più noti hanno avuto o un
grosso impulso da parte del marketing o sono stati usati per scrivere
qualcosa di notevole (i.e. un kernel). Il Pascal non rientra in queste
categorie ma a naso era l'unico linguaggio didattico(*) valido
disponibile.

Infatti.

[Gian Uberto Lauri]

Post by Gian Uberto Lauri
Esistono, ho avuto occasione di vederli, qualcosa di paragonabile
all'illuminazione zen :).

E'OF> Intendo dire... programmatori che *non* sbagliano? Voglio dire,
E'OF> un conto è sbagliare *poco*. Oppure sbagliare ma avere ampie
E'OF> skill nello scrivere i test/verifiche formali per cui poi gli
E'OF> errori vengono presi al volo. Ma *non* sbagliare proprio...

Uno, così ne ho visto uno. Tira fuori un istituto di tecnologia a caso
dove è andato a finire.

Uno un pochino meno bravo (questo ha seguito le lezioni) mi ha
raccontato di Arianne 5 a botto appena avvenuto :)...

Post by Gian Uberto Lauri
Vero. Ma essendo molti ed economici ci saranno manager che
affideranno progetti a homini visualbasicensis invece che a
programmatori di adatta capacità (ma maggiore costo).

E'OF> Non a caso il numero di 'bagni di sangue' è
E'OF> impressionante. Circa un progetto su quattro giunge a
E'OF> compimento, secondo le ultime statistiche che ho spulciato.

Ecco, hai capito in che industria non venire :).

*si riallaccia il giubbetto in kevlar*

Post by Gian Uberto Lauri
Per le categorie mi servirebbe un esempio per capire meglio il tuo
discorso.

E'OF> Se devi supportare più sistemi (metti qualche unix commerciale,
E'OF> linux, windows) ti trovi a lavorare con gli autotools in primo
E'OF> luogo.

O.K. Chiaro.

E'OF> A me Java non fa impazzire, ma complessivamente da questo punto
E'OF> di vista è un notevole passo avanti. E pure li ci sono delle
E'OF> storie dell'orrore, eh... Confesso che mi piace ancora di più
E'OF> Python, per queste cose.

Sapevo che ti piaceva il serpentastro. Anche se per lui ho visto qualche
rognetta di portabilità....

Post by Gian Uberto Lauri
Per lo scrivere... Si e no. Penso dipenda dall'esperienza.

E'OF> Ho circa 10 anni di esperienza nello scrivere C (e sono solo 10
E'OF> solo perchè sono giovane io). Eppure mi è molto più facile usare
E'OF> Ruby (che conosco solo da un anno).

Nessuno ha mai detto che C è facile :). Con C ci vuole "la forza".

Post by Gian Uberto Lauri
Certo, il C va bene con organizzazioni del lavoro tipo quelle ne
"il mitico mese uomo" (team di 10 persone in cui c'è un
programmatore senior, uno junior, un code lawyer e il resto
supporto).

E'OF> Dopo di che rimangono in dietro, allora aggiungono altri 10
E'OF> junior e non si fa più un accidenti del tutto :P

He he he... Se sono furbi accettano di rimanere indietro che il danno
altrimenti peggiora. Oppure pubblicano tutto su SourceForge :).

E'OF> Assolutamente e soprattutto si. Ma questo prescinde se il
E'OF> linguaggio client è Java, C o Python.

Indubbiamente. Ma anche quello è codice.

Certamente, tornando al fatto che vanno ottimizzate le parti critiche,
fare del C da corsa con dello SQL in grado di NON usare gli indici su
una applicazione dove il massimo del carico è nella esecuzione delle
query...

Post by Gian Uberto Lauri
Non mi convinci del tutto. Il discorso a naso torna perché non si
stanno considerando alcune variabili.

E'OF> IMHO scegliere un linguaggio di basso livello per un progetto
E'OF> software 'di alto livello' (ovvero di livello applicativo)
E'OF> rientra nel caso della 'premature optimization', se è fatto a
E'OF> scopo prestazionale.

Il discorso di tutte le variabili è ampio, e rientra nella classe dei
discorsi su quanto viene fatto in una maniera piuttosto che in un
altra perché non si mettono a bilancio, ad esempio, costi sostenuti da
terzi non implicati.

Non lo so, nessuno lo ha mai fatto, ma se si mettessero in conto tutti
i consumi energetici dovuti ad inefficenze del software, mi sa che
altro che standby dei televisori...

[Enrico 'Mc Osten' Franchi]

Post by Gian Uberto Lauri
Uno, così ne ho visto uno. Tira fuori un istituto di tecnologia a caso
dove è andato a finire.

MIT?

Post by Gian Uberto Lauri
Sapevo che ti piaceva il serpentastro. Anche se per lui ho visto qualche
rognetta di portabilità....

Si. Ci sono. Ma complessivamente poche.

Post by Gian Uberto Lauri
Nessuno ha mai detto che C è facile :). Con C ci vuole "la forza".

Lo sforzo, altro che! :P

Poi ribadisco, non direi che 'C è difficile'. Direi che usare C per
certe cose è difficile. Ci sono un sacco di cose per cui usare C viene
estremamente naturale e il linguaggio non mi aggiunge complessità.

Che so... penso ad un programma a caso che smazzula pacchetti di rete e
che se li deve analizzare/costruire crudi. Il fatto che C sia di livello
basso e dia sostanziale accesso crudo alla memoria è comodo.

Fare la stessa cosa in Python o in Java non mi viene altrettanto
naturale. Ma per altri compiti avere un linguaggio ad oggetti è
semplicemente *troppo* comodo.

Post by Gian Uberto Lauri
He he he... Se sono furbi accettano di rimanere indietro che il danno
altrimenti peggiora. Oppure pubblicano tutto su SourceForge :).

Ha LOL :)

Ma credo che ormai i manager abbiano capito che semplicemente triplicare
le persone non aiuta.

Post by Gian Uberto Lauri
Certamente, tornando al fatto che vanno ottimizzate le parti critiche,
fare del C da corsa con dello SQL in grado di NON usare gli indici su
una applicazione dove il massimo del carico è nella esecuzione delle
query...

Appunto.

Post by Gian Uberto Lauri
Il discorso di tutte le variabili è ampio, e rientra nella classe dei
discorsi su quanto viene fatto in una maniera piuttosto che in un
altra perché non si mettono a bilancio, ad esempio, costi sostenuti da
terzi non implicati.

Si.

Post by Gian Uberto Lauri
Non lo so, nessuno lo ha mai fatto, ma se si mettessero in conto tutti
i consumi energetici dovuti ad inefficenze del software, mi sa che
altro che standby dei televisori...

Attenzione però: scegliere di usare linguaggi di basso livello non
necessariamente minimizzerebbe i consumi. Tipicamente ottimizzare
software a livello algoritmico diventa più costoso (in opposizione con
l'ottimizzazione del singolo algoritmo nel software).

Crescerebbero anche i memory leak et similia. E su un sistema odierno
memory leak significa prima o tardi paginazione più intensa. Che è pure
questo uno spreco di CPU.

[Gian Uberto Lauri]

Post by Gian Uberto Lauri
Uno, così ne ho visto uno. Tira fuori un istituto di tecnologia a
caso dove è andato a finire.

E'OF> MIT?

Yep, è la testolina dietro FFTW ed ora Cilk Arts...

Post by Gian Uberto Lauri
Nessuno ha mai detto che C è facile :). Con C ci vuole "la forza".

E'OF> Lo sforzo, altro che! :P

Irriverente :)

E'OF> Che so... penso ad un programma a caso che smazzula pacchetti di
E'OF> rete e che se li deve analizzare/costruire crudi. Il fatto che C
E'OF> sia di livello basso e dia sostanziale accesso crudo alla
E'OF> memoria è comodo.

Ma non è una cosa semplice. Il C richiede che il programmatore sappia
quello che fa in quanto è tendenzialmente "obbediente". Dal lato
opposto c'è Java che controlla il controllabile.

Post by Gian Uberto Lauri
He he he... Se sono furbi accettano di rimanere indietro che il
danno altrimenti peggiora. Oppure pubblicano tutto su SourceForge
:).

E'OF> Ha LOL :)

E'OF> Ma credo che ormai i manager abbiano capito che semplicemente
E'OF> triplicare le persone non aiuta.

Ahem... "Stefano, Gian, chiamiamo un'altra persona ?"...

Post by Gian Uberto Lauri
Non lo so, nessuno lo ha mai fatto, ma se si mettessero in conto
tutti i consumi energetici dovuti ad inefficenze del software, mi
sa che altro che standby dei televisori...

E'OF> Attenzione però: scegliere di usare linguaggi di basso livello
E'OF> non necessariamente minimizzerebbe i consumi.

Infatti, vedi il gracconto di Graham sul programma per la ricerca dei
voli "appetibili" da un certo cliente: il programma in LISP con
algoritmi intelligenti che batte quelli ottimizzatissimi ma con
algoritmi grulli (non condivido l'idea che ha sui software patents, il
signore dovrebbe dare un'occhiata alla normativa europea...)

[Gian Uberto Lauri]

GUL> Infatti, vedi il gracconto di Graham sul programma per la ricerca
GUL> dei voli "appetibili" da un certo cliente: il programma in LISP
GUL> con algoritmi intelligenti che batte quelli ottimizzatissimi ma
GUL> con algoritmi grulli

Trovato il documento: http://www.paulgraham.com/carl.html
http://www.paulgraham.com/icad.html

[Enrico 'Mc Osten' Franchi]

Post by Gian Uberto Lauri
Trovato il documento: http://www.paulgraham.com/carl.html
http://www.paulgraham.com/icad.html

TY. Me lo leggiucchio.
Il secondo è splendido:

<<If you want to trick a pointy-haired boss into letting you write
software in Lisp, you could try telling him it's XML.>>

Mi chiedo cosa ci facciamo su un ng di Java.<g>

[Enrico 'Mc Osten' Franchi]

Post by Gian Uberto Lauri
Ma non è una cosa semplice. Il C richiede che il programmatore sappia
quello che fa in quanto è tendenzialmente "obbediente". Dal lato
opposto c'è Java che controlla il controllabile.

Mai lavorato in ADA <g>?

Post by Gian Uberto Lauri
Ahem... "Stefano, Gian, chiamiamo un'altra persona ?"...

E dire che io ho l'edizione *20-esimo* anniversario di Brooks. Del tipo
che anche leggendo un libro all'anno immagino che un manager avrebbe
potuto leggerselo.

Post by Gian Uberto Lauri
Infatti, vedi il gracconto di Graham sul programma per la ricerca dei
voli "appetibili" da un certo cliente: il programma in LISP con
algoritmi intelligenti che batte quelli ottimizzatissimi ma con
algoritmi grulli (non condivido l'idea che ha sui software patents, il
signore dovrebbe dare un'occhiata alla normativa europea...)

+1 su tutto.

[Gian Uberto Lauri]

Post by Gian Uberto Lauri
Ma non è una cosa semplice. Il C richiede che il programmatore
sappia quello che fa in quanto è tendenzialmente "obbediente". Dal
lato opposto c'è Java che controlla il controllabile.

E'OF> Mai lavorato in ADA <g>?

No, non c'era ancora un compilatore disponibile.

E poi la sai quella dell'unità di misura dell'intelligenza ? Il tary.

Ci sono le persone normali, intorno a qualche decina di tary. I geni
che vanno su percentuali significative, o superano, il kilotary. E gli
sfortunati, che girano sul decitary se non peggio sul centitary o il
millitary...

E'OF> Mi chiedo cosa ci facciamo su un ng di Java.<g>

"We were after the C++ programmers. We managed to drag a lot of them
about halfway to Lisp."

- Guy Steele, co-author of the Java spec

[Jack]

Post by Gian Uberto Lauri

Post by Gian Uberto Lauri
Ma non è una cosa semplice. Il C richiede che il programmatore
sappia quello che fa in quanto è tendenzialmente "obbediente". Dal
lato opposto c'è Java che controlla il controllabile.

E'OF> Mai lavorato in ADA <g>?

evitiamo di parlare di ADA. E' un linguaggio di programmazione
paranoico.

[Enrico 'Mc Osten' Franchi]

Post by Gian Uberto Lauri
No, non c'era ancora un compilatore disponibile.

Uh, allora no. Adesso si. Io comunque ne faccio a meno. Era tanto a
proprosito di linguaggi che tendono a controllare il controllabile.

Post by Gian Uberto Lauri
Ci sono le persone normali, intorno a qualche decina di tary. I geni
che vanno su percentuali significative, o superano, il kilotary. E gli
sfortunati, che girano sul decitary se non peggio sul centitary o il
millitary...

ROTFL.

Post by Gian Uberto Lauri
"We were after the C++ programmers. We managed to drag a lot of them
about halfway to Lisp."
- Guy Steele, co-author of the Java spec

Interessante. Anche se non sono sicuro che il programmatore Java tipo
sia sulla strada per Lisp. O forse questo da un interessante insight sul
perchè sempre più Javisti si stanno appassionando a Ruby.

[Enrico 'Henryx' Bianchi]

Post by Gian Uberto Lauri
Mi puoi indicare qualcosa di veramente notevole fatto in Ocaml?

MLDonkey

Enrico

[Enrico 'Mc Osten' Franchi]

Post by Enrico 'Henryx' Bianchi
MLDonkey

Omminghia. Non lo sapevo. Un RiK0 che mo 'si fa pirata' solo per usare
qualcosa in OCaml! :P

[P51D]

Post by Enrico 'Mc Osten' Franchi
Non ci vedo nulla di male, personalmente. Ci sono indubbi casi in cui i
puntatori e la gestione esplicita della memoria sono fondamentali (tipo
a breve dovrei scrivere il gestore della memoria per un interprete)....
Ma nella maggior parte dei casi, sono dettagli che non servono al
programmatore (a patto di avere un linguaggio ricco a sufficienza).
Chiediamoci in una tipica applicazione quando useremmo l'aritmetica dei
puntatori. Quando veramente serve, e quando invece bastano le reference...

Concordo su tutto: comunque io parlo in base alla mia espierienza, lunga ma
purtroppo non molto variata, quindi sono 10 anni che scrivo codice (image
processing) che non fa altro che elaborare lunghe sequenze di dati, e per
me, poter incrementare un puntatore invece di usare indici significa
dimezzare i tempi di elaborazione.

Giustamente si può obiettare: usa il C (o meglio l'assembly)! Si però mi si
raddoppiano i tempi di sviluppo + altri problemi, e mi concentro meno sul
problema da risolvere.

[Enrico 'Mc Osten' Franchi]

Post by P51D
Giustamente si può obiettare: usa il C (o meglio l'assembly)! Si però mi si
raddoppiano i tempi di sviluppo + altri problemi, e mi concentro meno sul
problema da risolvere.

E qui quoto.

[Enrico 'Henryx' Bianchi]

Post by P51D
Giustamente si può obiettare: usa il C (o meglio l'assembly)! Si però mi si
raddoppiano i tempi di sviluppo + altri problemi, e mi concentro meno sul
problema da risolvere.

Una soluzione che potrebbe salvare capra e cavoli e` l'uso di linguaggi
piu` moderni o piu` semplici rispetto al C, ma che permettono comunque
un approccio piu` a basso livello rispetto ai linguaggi interpretati. In
questo campo, penso che gli unici linguaggi disponibili siano il Pascal
e il D

Enrico

[Enrico 'Mc Osten' Franchi]

Post by Enrico 'Henryx' Bianchi
Una soluzione che potrebbe salvare capra e cavoli e` l'uso di linguaggi
piu` moderni o piu` semplici rispetto al C, ma che permettono comunque
un approccio piu` a basso livello rispetto ai linguaggi interpretati. In
questo campo, penso che gli unici linguaggi disponibili siano il Pascal
e il D

Io adoro D. Ma D è più vicino a Java come idea. Mi spiego meglio.
Java ha diverse caratteristiche peculiari. Nasce come linguaggio di
livello sostanzialmente medio (più alto del C, comparabile o più alto di
C++, ma comunque non alto come Python o Ruby) che però sia *più*
semplice del C++ sotto diversi aspetti.

In questo senso D risponde alla stessa domanda. Rispetto a Java è
compilato in codice nativo (mantenendo comunque una buona facilità di
installazione).

D'altra parte è comunque un linguaggio di livello parecchio più basso di
Python, Ruby o Perl. E' un linguaggio che si presta molto bene a carichi
computazionali, roba algortmica di basso livello etc etc etc. Ma per
scrivere software applicativo complesso non è *così* più semplice
rispetto a Java o addirittura C++.

Riguardo Pascal non mi esprimo. Conosco (poco ormai) il vecchio Pascal.
Il 'nuovo' Pascal (ma chiamiamolo anche Delphi, visto che di base
parliamo di quello) non lo ho mai usato. Mi dicono dalla regia che hanno
fixato alcune cose demenziali del vecchio pascal...

considera il codice Java

Person singer = SingerFactory.singerByName("Jagger")
ConcreteObject aDoor = singer.firstSeenObject()

if (aDoor != null && aDoor.isRed()){
aDoor.paintItBlack()
}

[ che ok, io ci userei un NullObjectPattern... ma d'accordo ]
Ecco... questo in Pascal una volta lo facevi con due if annidati. Ora
dicono che non sia più vero.

[P51D]

Post by Enrico 'Henryx' Bianchi
Una soluzione che potrebbe salvare capra e cavoli e` l'uso di linguaggi
piu` moderni o piu` semplici rispetto al C, ma che permettono comunque
un approccio piu` a basso livello rispetto ai linguaggi interpretati. In
questo campo, penso che gli unici linguaggi disponibili siano il Pascal
e il D
Enrico

D non l'ho mai sentito, mi informerò grazie. Pascal a me sembra un po' piu'
vecchio del C.

[Gian Uberto Lauri]

Post by Enrico 'Henryx' Bianchi
Una soluzione che potrebbe salvare capra e cavoli e` l'uso di
linguaggi piu` moderni o piu` semplici rispetto al C, ma che
permettono comunque un approccio piu` a basso livello rispetto ai
linguaggi interpretati. In questo campo, penso che gli unici
linguaggi disponibili siano il Pascal e il D
Enrico

P> D non l'ho mai sentito, mi informerò grazie. Pascal a me sembra un
P> po' piu' vecchio del C.

Pascal pare anche a me più anziano, se non altro perché nelle
primissime pagine del K&R si citano le macro per il begin e l'end - le
graffe potevano essere un problema di leggibilità per chi veniva dal
pascal e aveva delle stampanti un po' stanchine.

Basso livello il Pascal non direi, è un linguaggio didattico, nato per
essere compilato ed eseguito con poca spesa (il tempo macchina del
CDC6600 costava...).

Se poi uno con Pascal intende i prodotti Borland, questo è un'altro
discorso, il Turbo Pascal di Borland ha riportato quasi tutto ciò che
c'era in C ma con sintassi Pascal.

[Enrico 'Henryx' Bianchi]

Post by Gian Uberto Lauri
Basso livello il Pascal non direi, è un linguaggio didattico, nato per
essere compilato ed eseguito con poca spesa (il tempo macchina del
CDC6600 costava...).

A questo punto dipende anche cosa si intende per basso livello. Con il
Pascal si ha accesso diretto alle risorse della macchina, si puo`
scrivere asm in linea e si possono utilizzare i puntatori (per l'ultima
sono sicuro che sia una funzionalita` offerta dall'ISO Pascal, per le
altre mi sembra che fosse cosi`, ma non ci giurerei)

Post by Gian Uberto Lauri
Se poi uno con Pascal intende i prodotti Borland, questo è un'altro
discorso, il Turbo Pascal di Borland ha riportato quasi tutto ciò che
c'era in C ma con sintassi Pascal.

Da come lo dici sembra che sia una brutta cosa. Attualmente, tutti i
compilatori Pascal in circolazione si rifanno al dialetto di Borland,
permettendo cosi` un'alta portabilita` di codice. Per fare un esempio,
FreePascal permette di compilare il codice scritto per il compilatore
Borland senza problemi

Enrico

[Gian Uberto Lauri]

Post by Gian Uberto Lauri
Basso livello il Pascal non direi, è un linguaggio didattico, nato
per essere compilato ed eseguito con poca spesa (il tempo macchina
del CDC6600 costava...).

E'B> A questo punto dipende anche cosa si intende per basso
E'B> livello. Con il Pascal si ha accesso diretto alle risorse della
E'B> macchina, si puo` scrivere asm in linea e si possono utilizzare i
E'B> puntatori (per l'ultima sono sicuro che sia una funzionalita`
E'B> offerta dall'ISO Pascal, per le altre mi sembra che fosse cosi`,
E'B> ma non ci giurerei)

I puntatori c'erano, ma erano come i riferimenti di Java, li ottenevi,
li assegnavi ma non ci facevi I/O (salvo manovre sporche coi record
con varianti) e non ci facevi aritmetica, l'asm in linea credo sia
stata una estensione più tarda e non c'era sul 6600.

Post by Gian Uberto Lauri
Se poi uno con Pascal intende i prodotti Borland, questo è un'altro
discorso, il Turbo Pascal di Borland ha riportato quasi tutto ciò
che c'era in C ma con sintassi Pascal.

E'B> Da come lo dici sembra che sia una brutta cosa.

Beh, meglio la sintassi del C, il trasporto al Pascal di queste funzioni
anche se è stato utile non lo vedo come una cosa elegante.

[Jack]

Post by Enrico 'Mc Osten' Franchi

Post by Gian Uberto Lauri
Sicuro ? Sei proprio certo che *var non venga tradotto usando un
indirizzamento "secco" e var[i] un indirizzamento con displacement ?

Agli occhi del compilatore una scrittura del tipo
*(p + i) e p[i]
sono del tutto equivalenti (addirittura si mantiene la commutatività e
puoi scrivere i[p]). Questo è da standard.

figata, questo non lo sapevo. ora provo :)

[Gian Uberto Lauri]

Post by Enrico 'Mc Osten' Franchi
sono del tutto equivalenti (addirittura si mantiene la
commutatività e puoi scrivere i[p]). Questo è da standard.

J> figata, questo non lo sapevo. ora provo :)

Poi analizza questo codice e valutane l'output senza eseguirlo :)

main(){printf(&unix["\021%six\012\0"], (unix)["have"]+"fun"-0x60);}
[David Korn, AT&T Bell Labs
ioccc best One Liner, 1987 ]

[Gian Uberto Lauri]

P> C incremento il puntatore con "ptr++", e poi accedo agli elementi
P> con "*ptr". In Java sono costretto ad indicizzare ogni elemento
P> "ptr[indice]", ed incrementare l'indice. Esiste qualcosa di piu'
P> efficiente in Java?

No, non essendoci l'aritmetica sui puntatori. E comunque non peggiori
tanto le cose.

[Giulio Petrucci]

Post by Jack
Mmhh, io per l'universita' avevo fatto uno studio sugli algortimi di
sort, in java e in C. Java perdeva, a dipendenza dell'algoritmo, dallo
0 al 5 % di prestazioni risp allo stesso algoritmo scritto in C. Che
per un algortimo che dura 30 secondi non ti accorgi neanche, ma se
dura 2-3 giorni...beh, le cose cambiano...

Tempo addietro girava un articolo a riguarda (il titolo era qualcosa
tipo "Java and C++ comparision"). Non è che hai capito a quale articolo
mi riferisca? L'ho cercato in rete ma non ho trovato nulla e mi farebbe
piacere dargli uno sguardo...

Ciao,
Giulio

--

[r***@email.it]

Post by toto
Salve a tutti, per la tesi di laurea (non in informatica) devo sviluppare un
modello matematico.
Il C e' piu' performante di Java per calcoli matematici, vero?
posso integrare del codice in c in un programma java (cioe', java si occupa
della connessione a db, e visualizzazione gui, i calcoli li fa il C )
In questo caso, ovviamente si perde in termini di prestazioni che scrivendo
in puro C (credo)....ma tanto da vanificare il fatto che l'algoritmo sia
scritto in C?
Grazie mille per i consigli!!!!

Si' puo fare , java ha una tecnica standard per parlare con funzioni C
(JNI)
Ma non dovresti farlo, che senso ha usare mezzo Java e mezzo C?
Questa tecnologia e' stata pensata piu' che altro per permettere a
codice
Java di usare codice C GIA" esistente.
Se parti da zero, fai tutto in Java o tutto in C. A meno che non
tratti
di megaipersimulazioni non credo che avrai grossi probs di
performance.
Piu' che altro se usi un linguaggio chietiti perche' proprio quello.

[Enrico 'Mc Osten' Franchi]

Post by r***@email.it
Piu' che altro se usi un linguaggio chietiti perche' proprio quello.

+1

"Perchè conosco quello" in generale non è una buona risposta.