Newsgroup: it.comp.programmare
Titolo: [CONFRONTO] C++ vs Java vs Python (correzione benchmarks)

==============================================================
Ho deciso di riproporre il benchmark utilizzando lo script proposto da 
Lawrence Oluyede.
==============================================================
HARDWARE:    PIII 1Ghz, 512 Mb RAM
S.O.:        Linux SuSE 8.2 (kernel 2.4.19)
C++:         g++ 3.2
PYTHON:      Python 2.3 (#1, Aug 19 2003, 12:01:08) [GCC 3.2]
JAVA:        JDK 1.3.1 (09)
==============================================================
Il programma per il benchmark è il seguente:
        P1(N): Riempe un vettore di N elementi interi con 
                N numeri interi casuali.
==============================================================
Le tre implementazioni sono le seguenti:
--- CUT HERE, FILE: P1.py ---
# p1.py
# versione di Lawrence Oluyede e non di Azathot
import random
import sys
 
y = []
N = int(sys.argv[1])
 
for i in xrange(N):
   y.append(random.random())
--- CUT HERE ---
--- CUT HERE, FILE: P1.java ---
import java.util.Vector;
import java.util.Random;
class P1 {
        public static void main(String[] args) {
                Random r = new Random();
                Vector y = new Vector();
                for( int x = 0; x < N; ++x )
                        y.add( new Integer( r.nextInt( )  ) );
        };
}
--- CUT HERE ---
--- CUT HERE, FILE: P1.cpp ---
#include <iostream>
#include <deque>
using namespace std;
int main( ) {
        deque< int > y;
        for( int x = 0; x < N; ++x )
                y.push_back( rand( ) );
        return 0;
}
--- CUT HERE ---
==============================================================
Ovviamente, nel corso delle misurazioni, il valore di N verrà quantificato 
ed inserito prima della misurazione dei tempi di esecuzione.
Nessun compilatore o interprete compila/interpreta il codice con particolari 
ottimizzazioni (il g++ NON viene richiamato con l'opzione "-O3"). 
I tempi di esecuzione sono misurati con l'utilità "time" e corrispondono al 
tempo medio.
==============================================================
P1(1).py: 48.0 ms; P1(1).java: 280.6 ms; P1(1).cpp: 6 ms
P1(10).py: 48.0 ms; P1(10).java: 280.0 ms; P1(10).cpp: 6 ms
P1(100).py: 50.0 ms; P1(100).java: 288.0 ms; P1(100).cpp: 6 ms
P1(1000).py: 52.3 ms; P1(1000).java: 296.0 ms; P1(1000).cpp: 6 ms
P1(10000).py: 74,0 ms; P1(10000).java: 306.0 ms; P1(10000).cpp: 7 ms
P1(100000).py: 320.0 ms; P1(100000).java: 601.0 ms; P1(100000).cpp: 15 ms
P1(1000000).py: 2830.0 ms; P1(1000000).java: 3200.0 ms; 
        P1(1000000).cpp: 130 ms
RATIO Python/C++
1      : 8
10     : 8
100    : 8.3
1000   : 8.6
10000  : 12.7
100000 : 21.3
1000000: 21.7
RATIO Java/C++
[omissis]
RATIO Python/Java
[omissis]
==============================================================
CONCLUSIONI
==============================================================
In base alle rilevazioni, notiamo come la natura altamente dinamica del 
linguaggio Python insieme alla sua implementazione interpretata rappresenti 
un limite notevole per ciò che riguarda le risorse di calcolo necessarie.
Su tutti primeggia il C++ che, alla fine, è mediamente poco più di 10 volte 
più veloce del Python (cioè di almeno un ordine di grandezza).
==============================================================
-- 
---
*************** | Have you ever retired a human by mystake?
*** Azathot *** |
*************** | To contact me, ask me gently. Thanks.

 volte più veloce del Python (cioè di almeno un ordine di grandezza).
Beh dai sei passato da 500 volte a 10 volte ;-)
Ad ogni modo non hai ancora capito che la velocità di esecuzione non è
sempre tutto :) Continua pure con i tuoi bench
-- 
Lawrence "Rhymes" Oluyede
http://loluyede.blogspot.com
rhy...@NOSPAMmyself.com

 sempre tutto :)
Prova a dirlo ad un cliente che, avendo speso 150.000 euro di hardware e 
200.000 euro di software, per l'acquisto di 15 elaboratori per sostenere un 
determinato traffico, si vede costretto a spenderne altri 150.000 per 
raddoppiare la portata! Quanto pensi sia disposto ad accettare come markup 
da parte della tua azienda prima di sfancularti? 8-)


 da parte della tua azienda prima di sfancularti? 8-)
(notare, numeri a caso...)
"Con questa soluzione avete un costo iniziale per l'HW superiore del 40%
rispetto ad un sistema basato su c++, ma otterrete il prodotto finito in
100 giorni/uomo invece che 250, e un costo di manutenzione e aggiornamento
inferiore del 50% rispetto allo stesso progetto basato sul c++."
Ovviamente il nostro commerciale sarebbe capace di metterla in modo
migliore (per proporre i nostri sistemi in CF...) ma il succo della
questione č quello.
Che a conti fatti si traduce in un "La stessa cosa, con una macchina un pň
piů costosa, ma alla fin fine ad un prezzo piů basso e in minor tempo"
Ovviamente se si tratta di un motore di rendering la cosa cambia...
Raffaele
-- 
Raffaele Castagno
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 sfancularti? 8-)
Se la velocita' e' problema cosi' stringente allora dubito che il C++ sia il
linguaggio piu' indicato, specie per applicazioni cosi' orientate alla
manipolazione di grossi vettori numerici. Poprio per problemi simili il
fortran sembra cavarsela meglio.
Non meglissimo, ma meglio :)
Saluti.

 manipolazione di grossi vettori numerici. 
Con il C++ puoi addirittura realizzarti classi ad HOC dove puoi 
personalizzarti persino la politica di allocazione degli stessi! Prova a 
fare la stessa cosa in Python (... e avrai qualcosa che avrà bisogno di 10 
volte la potenza di calcolo che hai oppure che gestirà 1/10 delle 
utenze/traffico).
Ciao e salutami la salma... ahem, il FORTRAN... :)


 migliore 
Te l'ho detto, sei un commerciale sprecato per la programmazione.
Ciao ciccio


 realizzare qualcosa che va 10 volte più veloce, a parità di macchina.
Che fino a qualche ora fa erano 500 LOL :)


 Ciao e salutami la salma... ahem, il FORTRAN... :)
Io non parlo di python. Pero' ho confrontato routines vettoriali... il
fortran e' veramente efficiente in questo senso.
Sono confronti del tipo che hai fatto tu. Vince, anche se e' una salma. E se
hai fretta, devi usare anche quelle.
Saluti.

 fortran e' veramente efficiente in questo senso.
Mi puoi fare un esempio di programma in FORTRAN? Sarei interessato a fare 
dei benchmarks anche su quello sui calcoli vettoriali.
Ciao!


 Che fino a qualche ora fa erano 500 LOL :)
10 mi sembra già pesante come fattore moltiplicativo... considera che 
significa che hai bisogno di 10 macchine laddove te ne basterebbe una. ;-)


 significa che hai bisogno di 10 macchine laddove te ne basterebbe una. ;-)
Ah si... Io col cellulare connesso in GPRS ho un ritardo di 1 secondo e
quindi noto se il server invece di rispondermi in 3 ms mi risponde in 20
ms. E mi accorgo della differenza anche usando fastweb con un ritardo di
una decina di ms. Infatti sono in grado di cronometrare con precisione
millesimale anche gare di corsa.
Se uso un ambiente che mi sottopone a ritardi enormi (come internet per
esempio) a me cosa importa se impiego 3ms o 30ms? Se invece ho bisogno di
creare un ambiente di lavoro in cui devo fare calcoli molecolari o
simulazioni ambientali o previsioni metereologiche allora adottero` altri
linguaggi quali Fortran o C++.
Per tua informazione 
www.spec.org
 usa anche fortran. La Spec e`
un'organizzazione internazionale che definisce le prestazioni dei sistemi
di livello enterprise. La Top500 viene creata usando Linpack che e`
appunto una marea di roba matriciale da calcolare. Ma sono sicuro che tu
avrai lavorato con cose piu` professionali e serie. Pero` per te c'e` solo
il C++ quindi...
-- 
Valentino Volonghi, Regia SpA, Milan
Linux User #310274, Debian Sid Proud User

 fare dei benchmarks anche su quello sui calcoli vettoriali.
Il tuo esempio puo' andare bene. Anche qualcosa di piu' semplice.
Semplici operazioni algebriche su tutti gli elementi di un vettore. Tipo,
calcolarne la radice quadrata.
Usa pure STL, ovviamente, anche io avevo fatto cosi'.
Saluti.

 esempio) a me cosa importa se impiego 3ms o 30ms? 
Ti rispondo riportando un esempio dal mondo reale: quando un sistema viene 
dimensionato, di solito si effettua un dimensionamento basato sul carico 
medio, con modelli matematici che prendono in considerazione un carico 
distribuito temporalmente in maniera disomogenea. Un servizio 
(considerandolo come una "scatola nera") X si comporterà meglio di un 
servizio Y sotto carico se il suo tempo di interservizio t(X) è minore del 
tempo di interservizio dell'altro t(Y). Perchè?
Perché quando arriva l'orario di "punta", il sistema è soggetto più che in 
altri momenti ad un carico superiore a quello per cui è stato dimensionato.
Come tu ben sai, la latenza introdotta dal carico non è un fattore lineare 
con il carico stesso. Quindi, se diciamo impieghi 3 millisecondi per 
ottenere una risposta con 1 utente, con 10 utenti di norma è ben superiore 
a 30, diciamo 45 (questo dipende da altri fattori non parallellizzabili).
Quando arriviamo a 100 utenti, il ritardo non è di 300 ms, ma probabilmente 
di 700-800 ms. Cosa comporta tutto questo? Comporta che, come un effetto a 
domino, le linee di ritardo introdotte dal carico si appoggiano sui servizi 
dipendenti "a valle". In un sistema di media complessità, i servizi che 
lavorano per ottenere il risultato voluto sono decine, quindi puoi ben 
immaginare che introdurre un "collo di bottiglia" strutturale (perché di 
questo parliamo) può comportare dei rischi anche in ambienti apparentemente 
di scarsa criticità.
Se pensi che questo discorso significhi che invece di avere un risultato in 
10 millisecondi, ce l'ho in un secondo non cogli il nocciolo del prolema: 
potresti non ottenere PER NIENTE il risultato. Perché? Perché tutti i 
sistemi costruiti con un po' di raziocinio hanno meccanismi di timeout, che 
"scattano" non appena si raggiunge il ritardo massimo accettabile, e fanno 
magari ripetere la richiesta, generando ulteriore traffico, da cui una 
congestione completa del sistema.
Sebbene l'ora non mi permetta di fare discorsi più complessi ma sicuramente 
più interessanti, ti posso assicurare che anche in settori a "bassa 
criticità" come quelli Web, introdurre artificialmente dei ritardi per una 
scelta strutturale può essere un suicidio.
Alcune aziende si sono accorte di queste e stanno cercando di correre ai 
ripari... ma l'unica alternativa che vedono è quella di aumentare l'hw 
sottostante... mancando però di ottenere risultati apprezzabili...
Per quanto riguarda i discorsi sul FORTRAN, sono veramente interessato a 
ricevere da parte tua un benchmark simile a quello che ho fatto per gli 
altri linguaggi.
Ciao.


 altri linguaggi.
Fortran non lo conosco e non ho il tempo di impararlo anche perche` e` un
liguaggio dedicato a un mercato di nicchia quale e` appunto il calcolo
matriciale spinto. Se in universita` me lo faranno imparare, imparero`.


 Ciao e salutami la salma... ahem, il FORTRAN... :)
Non si parla di fortran77 ma di fortran95 se fai una bella ricerchina in
rete vedrai come non hai bisogno per certe applicazioni di scriverti
delle classi ad hoc, dato che in fortran95 esistono diversi comandi
introdotti da 50 di sviluppo ed utilizzo(**).
Un esempio?
Due vettori a e b
a = (/1,2,3,4,5/)
b = (/1,2,3,4,5/) 
in altri linguaggi per sapere se sono lo stesso vettore devi
implementare un algoritmo tu, in F95 basta un
if(any(a==b)) then...
ma ci sono altre belle cosette che non trovi in nessun altro linguaggio
come: ALL, FORALL, WHERE, ELSEWERE, altri ancora dei bei label su cicli che ne caso
di  piu' cicli annidati aumentano la leggibilita in modo notevole
esempio:
primo:do i=1,n
	...
	...
	...
	...
	...
	secondo: do j=1,n
		...
		...
		...
		...
		terzo : do x=1,n
			...
			quarto: do where(..)
			...
			...
			enddo quarto
			...
			...
		enddo terzo
		...
		...
		...
		...
	enddo secondo
	...
	...
	...
	...
	...
enddo primo
Vabbe qua le righe riportate sono poche, ma quando i cicli annidati sono
molti e non vanno in un unica schermata aiuta molto a capire dove termina un dato ciclo
E possibile usare dinamicamente la memoria grazie ad una dichiarazione
del tipo
integer, allocatable :: matrice(:,:,:,:,:,:)
che vuol dire semplicemente che al momento opportuno posso allocare una
bella matrice a 6 dimensione, e gestirla tranqullamente usando 6 indici.
Esistono pure delle belle funzioncine come SHAPE e RESHAPE che sono
molto piu' complete di un "barbaro" realloc.
Tutte cose che in C/C++ sono possibili ma si deve fare usando piccoli escamotage e possono inserire bug molto
subdoli da scovare.
e' possibile stampare a video direttamente un vettore/matrice senza
inserire dei for per scandire gli elementi.
Ma vediamo cosa mi viene ancora in mente... ahh si esistono un fottio di
funzioni realative alla generazione di numeri casuali sia interi che
double, oltre al fatto che gli algoritmi implementati sono piu'
affidabili rispetto al rand(), perche' hanno delle periodicita'
superiori, infatto sono implementazioni di algoritmi studiati per lo
scopo.
E' possibile eseguire tutte le belle operazioni di + - / * inversa,
trasposta, determinate, prodotto scalare senza scrivere codice
aggiuntivo, e quindi perdere tempo ed esporsi a BUG.
E' possibile dividere matrici e vettori secondo SLICE, proprio come in
Python a(3:10) tutti gli elementi dal terzo al decimo di un vettore.
E' possibile usare  una indicizzazione personalizzata di matrici e
vettori, es:
integer :: vett(-2:2)
crea un vettore di quatto elementi dove il primo ha indice -2 e il
quarto 2, tu dirai a che serve? Serve serve, per alcune formulazioni
matematiche ti permete di codificare la legge matematica dirattamente
dalla su scrittura sul testo.
In fortran95 e' possibile usare la OOP, quidi non e' detto che non
possano farsi delle classi ad hoc, identiche a quelle che faresti in C++
I compilatori hanno un vasto set di ottimizzazioni.
Esistono molte altre cose, che in C++ non sono presenti, per il semplice
fatto che Fortran e' un linguaggio per Scienziati ed Ingegneri che non
si occupano di programmazione, ma che hanno necessita' implementazione
al calcolatore, e non hanno tempo di perdersi nello studio di una cosa
complessa come il C++, in quanto hanno uno strumento pronto, affidabile,
e che evitera' loro di scrivere molto codice in piu' e quindi diminuire
i tempi per realizzare un certo software e debuggare, una cosa simile a
cio' che avviene per Python, che senso ha aver un applicazione che
termina il calcolo 2 ore prima, se per svilupparla e renderla affidabile
occorrono mesi contro le poche settimane impegate con un linguaggio piu'
adatto allo scopo?
Posso dichiare e usare dei puntatori in modo identico al C/C++.
Ovunque si fa ricerca ad un certo livello esistono implementazioni in
fortran, la maggior parte dei solutori FEM commerciali (sono dei
programmini che si usano su macchine con i controcazzi come CRAY e che
permettono effettuare le previsioni del tempo, di simulare terremoti, di
simulare strutture sottoposte a carico,sia statico che dinamico, in
entrambi i campi(lineare e non lineare)), quindi altro che dinosauro.
La diffusione maggiore e' nei settori:
Della fluidodinamica: (molto probabilmente le camere di combustione della
		     tua macchina e' stata ottimizzata grazie ad un FEM (mi sfugger il nome)
                     che nel suo settore e' il migliore e che guarda caso viene ancora
                     sviluppato ed aggiornato in fortran).
Nella Aeronautica : Attento il profilo alare del prossimo aereo che
		    predi e' venuto fuori da un algoritmo genetico
                    scritto in fortran, toccati i coglioni prima di
		    salire  :)
Nella Geotecnica  : Fondazioni,strutture ecc, come fai a dormire
e Ing. Strutturale  tranquillo in una casa venuta fuori da un programma
                    scritto in fortran e per di piu' da un vile ingegnere
		    civile che non capisce nulla di template, metodi e
                    puntatori?
                    Anche in questo caso toccati i coglioni mentre dormi
		    non si sa mai :)
Che il C++ sia un linguaggio dalle innumerevoli virtu' e' indiscutibile,
ma che sia *IL* linguaggio e' opinabile, in ogni settore e' stato
adottato e sviluppato un linguaggio adatto per determinati scopi, poi
ognuno usa cio' che vuole, ricordo ancora che trovai la home di un tizio
che aveva sviluppato un compilatore assembler usando uno scrip bash :)
Vorrei anche segnalarti alcuni link importanti cosi' che la prossima volta 
che provi a parlare di cose che non conosci ci rifletti un po' su e
corri a documentarti.
http://www.fortran.com/metcalf.htm
http://www.fortran.com
http://www.fortranlib.com/
http://www.jiscmail.ac.uk/lists/comp-fortran-90.html
http://www.absoft.com
http://www.compaq.com/fortran
http://www.cray.com/products/software/cf90.html
http://www.fr.fse.fujitsu.com/devuk/solaris.shtml
http://www.fr.fse.fujitsu.com/devuk/linux.shtml
http://www.hp.com/go/hpfortran
http://www.software.ibm.com/ad/fortran
http://www.intel.com/software/products/compilers/
http://www.nag.co.uk/
http://www.nasoftware.co.uk/home.html
http://wwws.sun.com/software/sundev/suncc/buy/index.html
http://wwws.sun.com/software/sundev/index.html
.
http://www.apogee.com
http://www.softek.co.jp
http://www.psrv.com/
http://www.winteracter.com
		-> un interessante GUI tool Kit per win e linux
Trovi un compilatore per qualsiasi architettura e sistema operativo, in piu' e' facile leggere nomi come:
INTEL
IBM
SUN
COMPAQ (e DIGITAL)
CRAY
che oltra a produrre Hardware sviluppano compilatori fortan ottimizzatissimi per le proprie macchine.
Io dire che c'e' un mercato ed una diffusione considerevole, certo che pero' non e' il mercato del C++, per il semplice
motivo che il C++ non e' consigliabile in tutti i campi pur essendo un linguaggio general purpose.
Una cosa poi in 51 anni (il fortran mi pare sia nato nel '52) hai idea
di quanti linguaggi siano nati e morti? eppute sto dinosauro (o salma
come la chiami tu) e' ancora presente e sviluppato oltre ad essere uno
dei linguaggi maggiormente usati alla NASA.
Tu pensi che il C++ arrivera' a 50 anni di vita? io credo di no, per un
semplice motivo (ma il mio e' il giudizio di un profano), dal punto di
vista della OOP stanno nascendo linguaggi che sull'esperienza del C++
permettono di rendere la vita piu' semplice al programmatore, e nulla di
strano che un girono un compilatore su codice simil-Python abbia una
velociata uguale ad un tradizionale compilatore C++ ma con una maggiore
semplicita di codifica.
Sul sito di intel trovi un gruppetto di manuali molto graziosi nel caso
tu voglia approndire, ma non credo che ti leggerai  migliaia di pagine.
Vabbo' sto cadendo in una guerra santa per difendere cosa un linguaggio
:) vabbe va chiudiamo.
Saluti
P.S.: Toglimi la curiosita, ma sei lo stesso di it.*.linux.software?

 
Io e' pochi mesi che maneggio il fortran ma fare delle provine interessa
pure me, se cmq voi approfondire meglio ti consiglio di postare su
comp.lang.fortran dove trovi gente molto preparata.
tornato al test
======= CODICE FORTRAN95 ============
 
program prova
implicit none
real    :: vett(dimensione a piacere)
call random_number(vett)
end
==================================
bello compatto no?, io purtroppo non dispongo di un pc bello performate
come il tuo, ma ho un misero
:/tmp$ cat /proc/meminfo
        total:    used:    free:  shared: buffers:  cached:
Mem:  263065600 161972224 101093376        0 19255296 100950016
Swap: 139821056        0 139821056
MemTotal:       256900 kB
MemFree:         98724 kB
MemShared:           0 kB
Buffers:         18804 kB
Cached:          98584 kB
SwapCached:          0 kB
Active:          56808 kB
Inactive:        88108 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:       256900 kB
LowFree:         98724 kB
SwapTotal:      136544 kB
SwapFree:       136544 kB
:/tmp$ cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 5
model           : 9
model name      : AMD-K6(tm) 3D+ Processor
stepping        : 1
cpu MHz         : 400.901
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr mce cx8 pge mmx syscall 3dnow
k6_mtrr
bogomips        : 799.53
Su una bella Debian GNU/Linux con kernel 2.4.20
ma vediamo cosa accade compilando senza ottimizzazioni:
Cmq faccio una prova con 1, 10, 100, 1000,1000000 e 1000000
1:
:/tmp$ ifc prova.f90 && time ./a.out
   program PROVA
8 Lines Compiled
real    0m0.007s
user    0m0.000s
sys     0m0.010s
10:
:/tmp$ ifc prova.f90 && time ./a.out
   program PROVA
8 Lines Compiled
real    0m0.007s
user    0m0.000s
sys     0m0.000s
100:
:/tmp$ ifc prova.f90 && time ./a.out
   program PROVA
8 Lines Compiled
real    0m0.007s
user    0m0.000s
sys     0m0.010s
1000:
:/tmp$ ifc prova.f90 && time ./a.out
   program PROVA
8 Lines Compiled
real    0m0.008s
user    0m0.000s
sys     0m0.010s
100000:
:/tmp$ ifc prova.f90 && time ./a.out
   program PROVA
8 Lines Compiled
real    0m0.027s
user    0m0.020s
sys     0m0.000s
1000000:
:/tmp$ ifc prova.f90 && time ./a.out
   program PROVA
8 Lines Compiled
real    0m0.214s
user    0m0.180s
sys     0m0.040s
I tuoi valori sono:
P1(1).cpp: 6 ms
P1(10).cpp: 6 ms
P1(100).cpp: 6 ms
P1(1000).cpp: 6 ms
P1(10000).cpp: 7 ms
P1(100000).cpp: 15ms
P1(1000000).cpp: 130 ms
Cio' il mio codice e' leggermente piu' lento del tuo, ma io ho un PC che
credo sia 10 volte meno performate del tuo.
I risultati sono buoni o no?
Cmq un test dove si notano meglio le caratteristiche del fortran 
sarebbe quello di gestire una bella matrice grossa
grossa e fare operazioni di shifting a destra a sinista, in alto e
basso e fare qualche bella operazione tra grosse matrici le fondamentali
+ * - /, lo scambio tra righe e colonne di matrici diverse.
Mhhh se trovo un secondo di tempo e un pizzico di voglia scrivo le
poche righe che occorrono.
Il ogni caso il must sarebbe eseguire calcoli algebrici seri, c'e' da
dire pero' che i compilatori fortran si appoggiano a blas, lapack e
linpak nativamente :) quindi non credo che il C++ ne uscirebbe indenne.
Mhhhh vado a cercare un bel libro di meccanica razionale :)
Ciao

Il Tue, 19 Aug 2003 22:29:14 +0200, Endymion fece sapere che:

Be' io la mia parte l'ho fatta ma non sono un mago della programmazione
:) anche se credo che la forza del fortran sia in calcoli piu' pensati. 

Dimenticavo un bel documento (anche se non tratta dell'ultimo standard)
e':
http://exodus.physics.ucla.edu/Fortran95/ExpressC++.pdf

Ecco qualcosa di serio
http://www.coyotegulch.com/reviews/almabench.html

Un confronto multipiattaforma tra C e obsoletissimmo fortran 77
http://www.aip.org/cip/langer.htm

Anche questo sembra interessante, ma devo leggerlo meglio.
http://www.osl.iu.edu/~tveldhui/papers/iscope97/
blit++ fa parte dello stardard c++?

 altri 150.000 per raddoppiare la portata!
glielo dici e stop. Se non gli va bene si fa in culo e spende il doppio 
per farsi fare il lavoro daccapo da qualche jena mangiacarogne come te. 
Nel frattempo l'azienducola tira le cuoia tossendo soldi, il capo è già 
scappato alle Maldive con la cassa e la segretaria e tutto il pagamento 
che ti ritrovi è un cappellino in poliestere della taglia sbagliata col 
logo della ditta. Rituale rogo in effigie del capo, asta fallimentare e 
fine della fiera. Contento? ora la finirai di rompere le palle con 'sta 
domanda idiota?
-- 
  < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.1.2. C, C++ and ASM developers
                               and beta testers are welcome!


Bello! Ma per quanto mi ricordo io del Fortran (poco :-D) non mi pare tu stia usando un
contenitore a dimensionamento variabile, nel tuo caso la dimensione e' definita
staticamente all'inizio del programma, confermi? Negli altri esempi Azatoth usa una
collezione in grado di dimensionarsi dinamicamente in base al numero di valori inseriti,
quindi il tuo esempio non mi sembra paragonabile.
Ciao,
    Bruno.
-- 
| Bruno Bossola 
| A Java Software Engineer :-)
| 
http://digilander.iol.it/bbossola
| Membro del JUG Torino - 
http://www.jugtorino.it

 Mhhhh vado a cercare un bel libro di meccanica razionale :)
Goldstein? :)
Saluti.

 
I miei risultati sono eccellenti o no?
Allora posso affermare che il miglior linguaggio e' il FORTRAN?
Sinceramente non lo direi mai, ma per velocita' e semplicita' in
ambito di calcolo sicuramente si, ma questo no lo dico a causa del
semplice e poco significativo test fatto, ma lo dicono persone che
giornalmente lavorano si con F95 che C++ e di cui ho postato i link
prima, tra questi c'e' uno realizzato nel 98 che asserisce che il C++ 
e veloce quanto il fortran, ma vorrei far notare che si riferisce al FORTRAN77 
cioe' un FORTRAN di 26 anni(21 all'epoca del test) che conosce bene ed 
ad un appena nato fortran90 (di cui non credo abbia grande competenza) dato 
che siamo nel 1998 e il fortran90 mi pare sia stato rilasciato nel 92/93 
i compilatori del tempo dovevano essere per forza di cose un po' scarsini 
a confronto dei piu' maturi compilatori C++ che mi pare siano nati verso 
la fine del 1980.
Da notare pure che alla fine l'autore dell'articolo nei ringraziamenti dice:
"...and colleagues at KAI provided helpful advice on the use of their
compiler."
Cioe' gli sviluppatori del compilatore KAI usato nei test gli hanno dato
una mano, mentre non si parla di nessun aiuto da parte degli
sviluppatori del compilatore F77/F90.
Ma nonostante cio' il C++ non regge il confronto con un orribile ed
oggettivamente obsoleto fortran77 (non ha nessuna forma di puntatori, di
tipi derivati, e non sa nemmeno cosa sia la ricorsivita', per non
parlare del formato fisso e dei goto con cui il codice deve essere
scritto).
I risultati migliori il C++ li ottiene con una libreria che non fa parte
delle librerie standard, ma estistono miliardi di librerie aggintive a
fortran realizzate per ogni specifico campo di calcolo ed ottimizzate
fino all'osso ma che nel test non sono state considerate.


No, non stai usando una collezione a dimensionamento dinamico, il tuo confronto non e'
significativo: leggi il mio post precedente.
Se cerchi comunque indietro su google trovi anche il codice java analogo al tuo, che usa
un array di interi invece di un Vector.



Mhh gia' purtroppo io non ho competenze di OOP e di uso dei puntatori in FORTRAN che farebbe 
quello che dici tu si protrebbe mandare un bel post a comp.lang.fortran, io riesco a leggere 
l'inglese ma a scrivere faccio pena.
Cmq se trovo tempo vedo di documentarmi meglio, non so se' hai
letto il post dove creo un vettore di interi, credo che anche tu sia
daccordo sul fatto che la velocita' e' veramente notevole.

 Goldstein? :)
A quanto ne so il Compaq come compilatore e' veramente ottimo, pero'
si trascina dietro qualcosa del M$ ProFortran che da qualche
incopatibilita', e' vero o mi sbaglio?
No un autore italiano, mi pare Muracchini ed un altro testo, pero' ora
ho veramente da fare, spero di trovare la testa ed il tempo per scrivere
qualcosa di "matricialmente"  parlando BRUTALE :)


Mhh ah gia'... non sono un grande esperto in programmazione, e non ho
mai usato i metodi di gestione della memoria del F95 ne tantomeno la
sua OOP, si protrbbe mandare un post su comp.lang.fortran dove c'e'
gente veramente competente, cercasi volontario per scriverlo :)
Daltro canto posso brutalmente spulciare la documentazione ed
implementare una normalissima lista senza nulla di complicato
=======================================================
program prova
use iflport
implicit none
type elemento
        integer :: valore
        type(elemento),pointer :: successivo
end type elemento
integer :: intero_casuale,i,n=1
type(elemento),pointer :: lista,corrente
do i=1,n
        intero_casuale = irand()
        allocate(corrente)
        corrente%valore = intero_casuale
        corrente%successivo => lista
enddo
end program prova
========================================================
Scusate se c'e' qualche vaccata ma e' la prima volta che uso i puntatori
in fortran (non li uso nemmeno in C)
Mi pare che il codice sia molto chiaro
esecuazione su un AMD K6-III a 400Mhz
1:
:/tmp$ ifc lista.f90 && time ./a.out
   program PROVA
21 Lines Compiled
real    0m0.007s
user    0m0.000s
sys     0m0.000s
10:
:/tmp$ ifc lista.f90 && time ./a.out
   program PROVA
21 Lines Compiled
real    0m0.007s
user    0m0.010s
sys     0m0.000s
100:
   program PROVA
21 Lines Compiled
real    0m0.007s
user    0m0.000s
sys     0m0.000s
1000:
:/tmp$ ifc lista.f90 && time ./a.out
   program PROVA
21 Lines Compiled
real    0m0.008s
user    0m0.000s
sys     0m0.010s
10000:
:/tmp$ ifc lista.f90 && time ./a.out
   program PROVA
21 Lines Compiled
real    0m0.020s
user    0m0.010s
sys     0m0.010s
100000:
:/tmp$ ifc lista.f90 && time ./a.out
   program PROVA
21 Lines Compiled
real    0m0.138s
user    0m0.100s
sys     0m0.040s
1000000:
:/tmp$ ifc lista.f90 && time ./a.out
   program PROVA
21 Lines Compiled
real    0m1.345s
user    0m1.010s
sys     0m0.320s
Che non mi sembrano malaccio come valori, credo comunque che esista una
soluzione migliore e piu' performante della mia, ma torno a ripeter che
il massimo del fortran lo si vede in corposi algoritmi di calcolo
Ad esempio da uno dei precedenti siti che ho indicato e' possibile
scaricare il file almabench-1.0.0.tar.gz dove il C++ esce con le ossa
rotte, il codice C++  lo potete vedere se scaricate il pacchetto 
Il mio GCC e' il 3.2.1
====================================================================
:/tmp/almabench-1.0.0/cpp$ g++ almabench.cpp
:/tmp/almabench-1.0.0/cpp$ time ./a.out
real    2m25.187s
user    2m22.290s
sys     0m0.030s
====================================================================
e ricompilando la versione Fortran95 senza ottimizzazioni ho il  
miracolo!!!
:/tmp/almabench-1.0.0/fortran$ ifc *.f90 -o pppp
   program ALMABENCH
64 Lines Compiled
   module ALMAUTIL
     module function ANPM
     module function PLANETPV
     module function RADECDIST
347 Lines Compiled
:/tmp/almabench-1.0.0/fortran$ time  ./pppp
real    1m34.943s
user    1m34.020s
sys     0m0.020s
Niete male direi.
P.S: Per chi non vuol scaricare il sorgente
//      A number-crunching benchmark designed for cross-language and
//      vendor
//      comparisons.
//
//      Written by Scott Robert Ladd.
//
//      No rights reserved. This is public domain software, for use by
//      anyone.
//
//      This program calculates the daily ephemeris (at noon) for the
//      years
//      2000-2099 using an algorithm developed by J.L. Simon, P.
//      Bretagnon, J.
//      Chapront, M. Chapront-Touze, G. Francou and J. Laskar of the
//      Bureau des
//      Longitudes, Paris, France), as detailed in Astronomy &
//      Astrophysics
//      282, 663 (1994)
//
//      Note that the code herein is design for the purpose of testing
//      computational performance; error handling and other such
//      "niceties"
//      is virtually non-existent.
//
//      Actual (and oft-updated) benchmark results can be found at:
//              
http://www.coyotegulch.com
//
//      Please do not use this information or algorithm in any way that
//      might
//      upset the balance of the universe or otherwise cause planets to
//      impact
//      upon one another.

 incopatibilita', e' vero o mi sbaglio?
Vero. Ma ci sono aggiornamenti apposta. Deriva da quella suite, e da'
qualche grattacapo se installi anche contemporaneamente Visual Studio (6).
Saluti.

 inferiore del 50% rispetto allo stesso progetto basato sul c++."
Io direi che molti linguaggi/tool permettono tempi di sviluppo
rapidi, ma questo avviene a discapito della qualità del sw e dei
tempi di manutenzione ed aggiornamento.
Se vuoi scrivere sw di adeguata qualità alla fine ci vuole più tempo che
se lo avessi scritto in C++.
Java è fra questi. Il python no.
Ciao.
-- 
BSD is for UNIX lovers -- linux is for Windows haters.

 ha scritto nel messaggio
news:Xns93DD19EF...@127.0.0.1...


 [...]
qualcosa del genere. Aggiungi un grafico a barre colorate ed è perfetto
-- 
  < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.1.3. C, C++ and ASM developers
