View Full Version : Test velocistico: 5M iterazioni C/C#/Java
Vash1986
18-07-2006, 23:19
Salve a tutti.
Gioco a Ultima Online, non sui server ufficiali bensì su quelli unofficial. Tali server necessitano di un "emulatore", ossia un programma che funga da server per tutti i client UO che si connettono, che emula lo stile di gioco ufficiale dei server EA GAMES.
Uno dei miei emulatori preferiti, per il quale scripto anche, è RunUO, scritto interamente in C#. Ed è proprio scriptando che ho notato che in pochi istanti vengono eseguite centinaia se non migliaia di righe di codice.
Il metodo per colpire gli avversari, il movimento, l'intelligenza dei mostri... e ci sono server a cui si connettono sino a 100 persone assieme che non vanno oltre il 10% di utilizzo cpu con un athlon 2000+.
Mi è dunque venuto un dubbio riguardo le potenzialità del C# e del framework e ho fatto un simpatico test.
Ho creato 3 programmini, rispettivamente in C, C# e Java, con una sola funzione/classe che eseguiva 5 miliardi di iterazioni.
for ( i = 0; i < 1000000; i++ )
for ( j = 0; j < 5000; j++ )
a = 0;
Premetto che ho un a64 3200+ venice non overclockato, 1gb di ram 400mhz.
Il primo colpo mi è venuto quando la virtual machine di Java è riuscita a fare il tutto in 16s mentre l'eseguibile C ha impiegato 17s.
Poi ho scoperto con estremo stupore che "runnando" il programma in SharpDevelop (C#) ha impiegato SOLAMENTE 7s.
Qui c'è qualcosa che decisamente non mi torna... il C è conosciuto come uno dei linguaggi più efficaci e veloci. Certo non mi aspettavo che battesse il Java su operazioni elementari come un semplice ciclo for, ma non capisco davvero come sia possibile che il C# abbia impiegato meno di metà del tempo!
Voi che ne pensate?
redcloud
19-07-2006, 00:30
Ho appena fatto una prova tra C e Java su Debian e Sempron a 1800MHz.
C - 19sec
Java - 9 sec
Contate che qui può intervenire il loop unrolling... Ora non mi ricordo se i compilatori C/C++ lo fanno in automatico senza particolari opzioni di compilazione, ma probabilmente Java e C# lo fanno...
In pratica sostituiscono quelle chiamate con una lista di a = 0;
Prova ad immettere i e j da linea di comando:
for ( i = 0; i < argv[1]; i++ )
for ( j = 0; j < argv[2]; j++ )
a = 0;
e fate la stessa cosa per Java e C#...e vederete che probabilmente cambierà qualcosa...
trallallero
19-07-2006, 09:38
Contate che qui può intervenire il loop unrolling... Ora non mi ricordo se i compilatori C/C++ lo fanno in automatico senza particolari opzioni di compilazione, ma probabilmente Java e C# lo fanno...
In pratica sostituiscono quelle chiamate con una lista di a = 0;
Prova ad immettere i e j da linea di comando:
for ( i = 0; i < argv[1]; i++ )
for ( j = 0; j < argv[2]; j++ )
a = 0;
e fate la stessa cosa per Java e C#...e vederete che probabilmente cambierà qualcosa...
sicuramente la prima cosa che cambierá é che ti dará almeno un warning sul
i < argv[1]
:read:
ce lo mettiamo un atoi ? :D
scherzi a parte, non puó essere che magari il java o il C# hanno un compilatore "intelligente" che vede che ci sono migliaia di istruzioni identiche e semplicemente ... non le esegue ?
sottovento
19-07-2006, 10:33
In effetti, come dice trallallero, molti compilatori semplicemente eliminano questo codice. Uno di questi, se non sbaglio, e' proprio gcc con qualche strana opzione di ottimizzazione.
In questo caso, pero' si avrebbe un tempo di calcolo uguale a zero.
Una considerazione: il codice da eseguire e' davvero poco, e non puo' essere tradotto in macchina in modi cosi' diversi.
Sarebbe interessante comparare il codice generato. Per esempio, gcc -S dovrebbe generare il codice assembler. Anche Java ha un'opzione simile (sorry, non la ricordo!).
Cmq la differenza di 1 secondo potrebbe non essere significativa: potrebbe dipendere dal criterio usato per il calcolo dei tempi e dalle precisioni, sempre che ripetendo parecchie volte la prova non persista :)
scorpion89
19-07-2006, 11:23
Provando a usare qualke opzione di gcc il risultato è 1secondo.
usando queste opzioni
gcc -malign-double -funroll-all-loops -Os
trovate googlando un po' :D
Ciao
Sicuramente i compilatori jit di java e c# riescono ad intercettare le istruzzioni duplicate ad ogni ciclo e ad eliminarle. Questo puo farlo anche un compilatore C come gcc ma ci si deve ricordare di specificare un livello di ottimizzazione maggiore di 0.
$ gcc -O0 test.c -o test
$ time ./test
real 0m13.541s
user 0m12.065s
sys 0m0.212s
Mentre gia con -O1 C spazza via Java e C#
$ gcc -O1 test.c -o test
$ time ./test
real 0m0.005s
user 0m0.000s
sys 0m0.000s
ciao ;)
Vash1986
19-07-2006, 11:42
Avevate ragione, ho spuntato le opzioni di ottimizzazione e ora il nuovo eseguibile C arriva a fare il tutto in 7s, ovvero con la stessa velocità del C#.
redcloud per caso hai settato qualche opzione di ottimizzazione per java?
redcloud
19-07-2006, 11:48
Avevate ragione, ho spuntato le opzioni di ottimizzazione e ora il nuovo eseguibile C arriva a fare il tutto in 7s, ovvero con la stessa velocità del C#.
redcloud per caso hai settato qualche opzione di ottimizzazione per java?
No, Java è talmente pulito che fa tutto da se :D
Vash1986
19-07-2006, 11:50
No, Java è talmente pulito che fa tutto da se :D
Allora o la virtual machine di windows fa veramente pena oppure il tuo Sempron con Debian dà legnate al mio A64 con Winzoz XP :doh:
BountyKiller
19-07-2006, 11:52
se hai usato il visual studio hai compilato in release???
anch'io ho fatto qualche test velocistico ma sull'assmebly......ho scoperto con mi grande sorpresa che un'operazione di increment su un registro è il 10% più lentachei non caricare 1 in un registro e poi sommarlo all'accumulatore...... :eek:
Vash1986
19-07-2006, 12:53
Stavolta ho fatto un programma un po' più serio, e compilando sia in C che in C# con le dovute ottimizzazioni.
Calcolo 500 volte pi greco. Ogni singolo calcolo esegue 2 milioni di somme/sottrazioni secondo la formula di Leibniz.
pi/4 = 1/1 - 1/3 + 1/5 - 1/7 + 1/9 ...
C - 1,5s
double calcPiQuarti()
{
double pi = 0;
int i;
char sign = 1; // 1 = plus, 0 = minus
for ( i = 1; i < 2000000; i += 2 )
{
if ( sign )
{
pi += ( 1.0 / (double)i );
sign = 0;
}
else
{
pi -= ( 1.0 / (double)i );
sign = 1;
}
}
return pi;
}
int main()
{
double prova; int i,b;
printf( "Il valore di pi greco e': %f\n", calcPiQuarti()*4 ); // Verifica esattezza: OK! 3.141592
for ( i = 0; i < 500; i++ )
b = calcPiQuarti();
system("pause"); // non funziona su linux, su windows aspetta la pressione di un tasto con "Premere un tasto per continuare..."
return 0;
}
C# - 6s
using System;
namespace prova
{
class MainClass
{
public static void Main(string[] args)
{
int i; double j;
Console.WriteLine("Hello World!");
for ( i = 0; i < 500; i++ )
j = calcPiQuarti();
Console.WriteLine("Ho finito");
}
static double calcPiQuarti()
{
double pi = 0;
int i;
bool sign = true;
for ( i = 1; i < 2000000; i += 2 )
{
if ( sign )
{
pi += ( 1.0 / (double)i );
sign = false;
}
else
{
pi -= ( 1.0 / (double)i );
sign = true;
}
}
return pi;
}
}
}
Java - 6s
public class Prova
{
public static void main(String[] args)
{
System.out.println( "Il valore di pi greco è:" + calcPiQuarti()*4 );
double a;
for ( int i = 0; i < 500; i++ )
a = calcPiQuarti();
System.out.println( "Finito!" );
}
static double calcPiQuarti()
{
double pi = 0;
int i;
char sign = 1; // 1 = plus, 0 = minus
for ( i = 1; i < 2000000; i += 2 )
{
if ( sign == 1 )
{
pi += ( 1.0 / (double)i );
sign = 0;
}
else
{
pi -= ( 1.0 / (double)i );
sign = 1;
}
}
return pi;
}
}
A quanto pare il C è vincitore :D
trallallero
19-07-2006, 13:00
...
A quanto pare il C è vincitore :D
avevi dubbi ? :D
Marinelli
19-07-2006, 13:47
Utilizzato l'ultimo programma di Vash, in C:
- compilato con Dev-C++ ==> 21s
- compilato con Intel C++ compiler ==> non fa neppure a tempo a comparire la finestra che ha già finito ;)
In Java: circa 17,5s
Ciao :)
P.S. Il processore è un PIII 1000E, su Asus P3b-f
sottovento
19-07-2006, 14:07
...
A quanto pare il C è vincitore :D
Beh, occorre fare un minimo di attenzione. In questo caso le cose sono semplici, ma non e' sempre cosi'.
C non fa alcun controllo sui dati, non solleva eccezioni nei casi singolari e tutto il resto.
Inoltre: hai compilato con le opzioni di ottimizzazione del compilatore?
Come suggerito prima, non ci sono tantissimi modi per tradurre in macchina questo codice, puoi controllare l'assembler generato, e a questo punto e' facile capire il motivo di una simile differenza.
High Flying
Sottovento
ilsensine
19-07-2006, 14:10
Mentre gia con -O1 C spazza via Java e C#
$ gcc -O1 test.c -o test
$ time ./test
real 0m0.005s
user 0m0.000s
sys 0m0.000s
Grazie, dai una occhiata al disassemblato ;)
Hai appena misurato il tempo di startup di una applicazione sotto linux :D
sottovento
19-07-2006, 14:24
Grazie, dai una occhiata al disassemblato ;)
Hai appena misurato il tempo di startup di una applicazione sotto linux :D
:D Inutile guardare il disassemblato, direi :D
scherzi a parte, non puó essere che magari il java o il C# hanno un compilatore "intelligente" che vede che ci sono migliaia di istruzioni identiche e semplicemente ... non le esegue ?
Sicuramente...ma quella è una particolarità del ciclo che è stato usato... In generale il loop unrolling può essere fatto con qualsiasi ciclo di una lunghezza predeterminata...
Vash1986
19-07-2006, 16:29
Beh, occorre fare un minimo di attenzione. In questo caso le cose sono semplici, ma non e' sempre cosi'.
C non fa alcun controllo sui dati, non solleva eccezioni nei casi singolari e tutto il resto.
Inoltre: hai compilato con le opzioni di ottimizzazione del compilatore?
Lo so che il C non esegue alcun controllo, infatti è per questo che è più veloce.
Certo, ho compilato con le ottimizzazioni sia di C# che C.
Ma a voi risulta che applicazioni C++ siano meno performanti di applicazioni C? Altrimenti non mi spiegherei perchè quasi tutto su linux è fatto in C.
The3DProgrammer
19-07-2006, 17:11
beh in linea teorica l'uso massiccio di classi polimorfiche potrebbe rallentare l'esecuzione, causa meccanismo delle vtables. In pratica non credo che il rallentamento sia così netto (devo convertire l'engine raytracing che sto scrivendo in C, ti saprò dire in futuro ;))
ciau
Lo so che il C non esegue alcun controllo, infatti è per questo che è più veloce.
Certo, ho compilato con le ottimizzazioni sia di C# che C.
Ma a voi risulta che applicazioni C++ siano meno performanti di applicazioni C? Altrimenti non mi spiegherei perchè quasi tutto su linux è fatto in C.
Il C rimane comunque più performante del C++. Per esempio è pensabile sostituire un Oggetto C++ con una Struttura C (attributi) ed un Array di puntatori a funzione (metodi) - almeno io lo farei così - ... la soluzione C avrebbe le stesse funzionalità ma opererebbe più velocemente (almeno credo :stordita: ).
In Linux tutto o quasi è ancora in C perché funziona sufficientemente bene e quel codice non è soggetto a modifiche, in più pensare di riscrivere una buona parte del kernel in C++ (che generalmente una volta acquisito il metodo di programmazione ad oggetti viene più naturale) sarebbe piuttosto oneroso in termini di tempo.
Il C rimane comunque più performante del C++. Per esempio è pensabile sostituire un Oggetto C++ con una Struttura C (attributi) ed un Array di puntatori a funzione (metodi) - almeno io lo farei così - ... la soluzione C avrebbe le stesse funzionalità ma opererebbe più velocemente (almeno credo :stordita: ).
Imho avrebbe le stesse prestazioni ;) Di fatto fai le stesse operazioni...anzi ne faresti di più in C perchè devi indicizzare il vettore di puntatori a funzione... Al contrario in C++ il nome dei metodi delle classi viene tradotto staticamente dal compilatore, mentre il metodo dei "puntatori" viene usato solo per i metodi virtual...
Vash1986
19-07-2006, 20:19
Imho avrebbe le stesse prestazioni ;) Di fatto fai le stesse operazioni...anzi ne faresti di più in C perchè devi indicizzare il vettore di puntatori a funzione... Al contrario in C++ il nome dei metodi delle classi viene tradotto staticamente dal compilatore, mentre il metodo dei "puntatori" viene usato solo per i metodi virtual...
Quindi secondo te non è l'utilizzo di un linguaggio o l'altro a determinare il rallentamento, ma è la programmazione orientata agli oggetti che per forza di cose necessita di maggiori risorse di calcolo e memoria rispetto a una programmazione procedurale, giusto?
Ossia tentando di simulare gli oggetti in C cadremmo nelle stesse perdite prestazionali del C++?
che io sappia il C a livello teorico è più performante del C++ perchè per trattare le classi bisogna comunque tenere conto di un bell'overhead di puntatori. la cosa però all'atto pratico ha scarsa importanza perchè ormai tutti i compilatori sono ultraottimizzati, le CPU sono stratosferiche e inoltre in qualche caso la programmazione a oggetti può condurre a un miglior disegno del codice che potrebbe determinare un'efficienza migliore. fatto sta che programmare a oggetti in C si può anche se non è così comodo e si può fare anche in maniera lievemente più efficiente (in termini puramente velocistici) del C++ ma finchè mjordan non ci fa il tutorial che aveva promesso :mad: :read: :D
Vash1986
19-07-2006, 20:46
le CPU sono stratosferiche
E' proprio xkè i programmatori pensano alle cpu stratosferiche e alle enormi quantità di ram che il software diventa sempre più pesante.
Quando nel task manager di windows guardo i vari svchost.exe da 10mb l'uno, o quando guardo l'utilizzo ram di firefox o konqueror su linux mi viene da piangere.
E' proprio xkè i programmatori pensano alle cpu stratosferiche e alle enormi quantità di ram che il software diventa sempre più pesante.
Quando nel task manager di windows guardo i vari svchost.exe da 10mb l'uno, o quando guardo l'utilizzo ram di firefox o konqueror su linux mi viene da piangere.
no beh.. quelle sono applicazioni un tantino complesse.. non è così facile il discorso. firefox e konqueror occupano tanta memoria perchè hanno la necessità di tenere in memoria tanti dati (cache) per poterli visualizzare in futuro istantaneamente senza doverli scaricare nuovamente. poi con konqueror tra un pò ci fai il caffè e spegni la luce in bagno.. questa flessibilità la paghi in qualche maniera. il problema di firefox è anche il fatto di essere multipiattaforma e quindi non si appoggia mai alle librerie native (e quindi più performanti) del sistema in cui viene eseguito.
direi che fare programmi di quella portata in C non porta a grandi vantaggi.. teoricamente l'eseguibile dovrebbe essere più veloce, ma proprio la difficoltà nel fare un'applicazione di quel genere senza un supporto alla programmazione a oggetti, porta in media a più bugs/memory leak (cioè memoria non più utile che non viene deallocata) nel codice e quindi è anche possibile (e anche frequente) che il risultato finale sia peggiore (e soprattutto ci si impiega di più ad avere un risultato).
in sostanza non è vero che i programmatori se ne sbattono dell'efficienza, ma si è capito che la maniera migliore per rendere un programma efficiente è progettarlo in modo che sia efficiente, non limitarsi a scrivere codice di per se efficiente... non so se mi sono spiegato :stordita:
Vash1986
19-07-2006, 21:08
So perfettamente cosa intendi. Nel primo post se noti parlavo di un emulatore, RunUO, scritto in C#, che in 1 anno di sviluppo aveva già surclassato prepotentemente gli altri emulatori (scritti in C) che avevano milioni di bug ed erano molto meno performanti.
Ma è anche vero che è cmq importante badare, finchè possibile, di fare programmi il più possibile leggeri, e saper programmare in maniera efficiente in linguaggi di livello un po' + basso di quelli a oggetti, è molto utile.
Pensa che in quake3 ci sono alcune parti fatte in ASM =)
Ma mi sorge un dubbio cmq... il memory leak non avviene quando viene allocata (quindi prevalentemente con malloc) una zona di memoria, senza poi deallocarla?
La malloc però deve essere assegnata a un puntatore... E quindi non si può fare una semplicissima utility che scannerizzi i sorgenti C e faccia una lista di tutti i puntatori che vengono fatti puntare a una zona di memoria, e che poi in un secondo tempo verifichi che TUTTI sono stati deallocati con free?
So perfettamente cosa intendi. Nel primo post se noti parlavo di un emulatore, RunUO, scritto in C#, che in 1 anno di sviluppo aveva già surclassato prepotentemente gli altri emulatori (scritti in C) che avevano milioni di bug ed erano molto meno performanti.
esatto :D
Ma è anche vero che è cmq importante badare, finchè possibile, di fare programmi il più possibile leggeri, e saper programmare in maniera efficiente in linguaggi di livello un po' + basso di quelli a oggetti, è molto utile.
posso quasi capire un kernel (perchè è cruciale).. o un programma banale (perchè è semplice).. ma ormai qualsiasi programma serio è di una complessità non gestibile in C, o per cui non è conveniente usare C. ti dico solo che gli sviluppatori di GNOME hanno passato la loro vita a sostenere che o C o la morte e adesso dicono che C# è la via del futuro... :rolleyes: usare C++ no eh? ah lo usa già KDE :asd:
Pensa che in quake3 ci sono alcune parti fatte in ASM =)
ma certamente! quella è un'applicazione dove alcune parti sono critiche per le performance.. è molto complicato ma dove ci sono grossi investimenti si fa anche questo.
Ma mi sorge un dubbio cmq... il memory leak non avviene quando viene allocata (quindi prevalentemente con malloc) una zona di memoria, senza poi deallocarla?
La malloc però deve essere assegnata a un puntatore... E quindi non si può fare una semplicissima utility che scannerizzi i sorgenti C e faccia una lista di tutti i puntatori che vengono fatti puntare a una zona di memoria, e che poi in un secondo tempo verifichi che TUTTI sono stati deallocati con free?
ehm.. quello che dici è letteralmente impossibile.. lo sviluppo del programma non è prevedibile. qua si entra in questioni di computabilità che non vorrei affrontare perchè mi ricordano i brutti periodi di informatica teorica.. comunque se fosse possibile quello che dici te sarebbe anche possibile creare un'utility che dato un codice ti dice che ha un bug. cosa evidentemente non possibile ;)
Vash1986
19-07-2006, 21:53
ehm.. quello che dici è letteralmente impossibile.. lo sviluppo del programma non è prevedibile. qua si entra in questioni di computabilità che non vorrei affrontare perchè mi ricordano i brutti periodi di informatica teorica.. comunque se fosse possibile quello che dici te sarebbe anche possibile creare un'utility che dato un codice ti dice che ha un bug. cosa evidentemente non possibile ;)
Uhm... penso di capire anche se molto superficialmete.
Ma i memory leak si possono evitare programmando in C++? Perdonate l'ignoranza ma conosco solo C e Java al momento :P
Java poi è un capolavoro... ha un garbage collector che evita i leak ma poi è la Virtual Machine ad andare in leaking (perchè chiaramente non è scritta in java ahah).
Uhm... penso di capire anche se molto superficialmete.
Ma i memory leak si possono evitare programmando in C++?
Con un garbage collector li puoi evitare anche con il C++ :D
In realtà in C++ ci si trova negli stessi problemi del C, anche se sono sicuramente minori se si "programma bene"...
Vash1986
19-07-2006, 22:10
Con un garbage collector li puoi evitare anche con il C++ :D
In realtà in C++ ci si trova negli stessi problemi del C, anche se sono sicuramente minori se si "programma bene"...
Volendo il D è un C++ migliorato con garbage collector :P
Uhm... penso di capire anche se molto superficialmete.
Ma i memory leak si possono evitare programmando in C++? Perdonate l'ignoranza ma conosco solo C e Java al momento :P
Java poi è un capolavoro... ha un garbage collector che evita i leak ma poi è la Virtual Machine ad andare in leaking (perchè chiaramente non è scritta in java ahah).
nessun linguaggio può evitare i memory leak... diciamo che programmare a oggetti aiuta a organizzare meglio il codice. ad esempio in C++ puoi definire il distruttore di un oggetto, il che significa che quando l'oggetto viene distrutto (non vuol dire deallocato) puoi definire la maniera in cui deallocare tutta la memoria che non serve più. questo è molto più comodo e ordinato che andarsi a ricordare quando deallocare memoria e perchè in mezzo a mille righe di codice.
java usa un garbage collector come molti linguaggi "interpretati" (tra " perchè sono semi-compilati), ma in realtà esistono dei garbage collector anche per C++, solo che non fanno parte del linguaggio stesso. che poi la questione GC è tutt'altro che chiusa è un altro conto... però le potenzialità ci sono. si dice infatti che in java1.6 il GC sarà migliorato sensibilmente. direi che l'unica strada per evitare i memory leak è proseguire la ricerca del GC migliore ;) altrimenti si fa affidamento alle sole abilità del programmatore che è pur sempre un umano :D
Volendo il D è un C++ migliorato con garbage collector :P
Basta aggiungere un garbage collector al C++...ce ne sono diversi già pronti...oppure un garbage collector con il reference counting si può fare in pochi minuti ;)
Tre secoli di clima dentro un computer
il Giappone studia il riscaldamento globale
TOKYO - Difficile prevedere cosa succederà al clima del nostro pianeta tra 300 anni? Forse, ma non impossibile. Soprattutto se, come ha reso noto il ministro giapponese dell'educazione, si usa il secondo computer più veloce del mondo. Che verrà messo al lavoro per predire uragani, siccità, tempeste, insomma tutto quanto possa essere messo in relazione con il riscaldamento del pianeta Terra per i prossimi 30 anni. Primo step di una ricerca più ambiziosa che intende allargare le previsioni ad un range di 300 anni.
http://www.repubblica.it/2006/06/sezioni/scienza_e_tecnologia/terra-surriscaldata/30-anni-previsioni-meteo/30-anni-previsioni-meteo.html
http://www.thocp.net/hardware/nec_ess.htm
http://www.hpfpc.org/index-E.html
a2000: non è che hai sbagliato thread ? :)
Vash1986
19-07-2006, 22:54
a2000: non è che hai sbagliato thread ? :)
magari si scopre che il software che gira su quel pc è fatto in Java :Prrr:
The Earth Simulator consists of 640 supercomputers that are connected by a high-speed network (data transfer speed; 12.3 GBytes). Each supercomputer (1 node) contains eight vector processors with a peak performance of 8GFlops and a high-speed memory of 16 GBytes. The total number of processors is 5120 (8 x 640), which translates to a total of approximately 40 TFlops peak performance, and a total main memory of 10 TeraBytes.
35.61 TFlops is achieved from the operation of 638 nodes (5,104 processors) and an efficiency performance percentage of 87.2%.
According to the TOP500 list of supercomputers in the world, the second is the ASCI White system in the US, whose performance is 7.266 TFlops (peak performance 12.288 TFlops, peak performance percentage 58.8%). The Earth Simulator has five times the capacity of the US system.
Earth-Simulator runs at 35860.00 GFlops and is installed at Earth Simulator Center Japan Research it contains 5120 vector processors and peaks at 40960.00 GFlops
Based on the NEC SX architecture, 640 nodes, each node with 8 vector processors (8 Gflop/s peak per processor), 2 ns cycle time, 16GB shared memory. Total of 5120 total processors, 40 TFlop/s peak, and 10 TB memory.
It has a single stage crossbar (1800 miles of cable) 83,000 copper cables, 16 GB/s cross section bandwidth.
700 TB disk space
1.6 PB mass store
Area of computer = 4 tennis courts, 3 floors
Rmax from LINPACK MPP Benchmark Ax=b, dense problem
Linpack Benchmark = 35.6 TFlop/s
Problem of size n = 1,041,216; (8.7 TB of memory)
Half of peak (n ½ ) achieved at n ½ = 265,408
Benchmark took 5.8 hours to run.
Software: for the most part Fortran using MPI
Java, nuova scossa di terremoto
torna la paura dello tsunami
http://www.repubblica.it/2006/07/sezioni/esteri/terremoto-indonesia/polemiche-tsunami/polemiche-tsunami.html
Vash1986
19-07-2006, 23:09
Software: for the most part Fortran using MPI
...
Java, nuova scossa di terremoto
ahah :rolleyes:
...
posso quasi capire un kernel (perchè è cruciale).. o un programma banale (perchè è semplice).. ma ormai qualsiasi programma serio è di una complessità non gestibile in C, o per cui non è conveniente usare C. ti dico solo che gli sviluppatori di GNOME hanno passato la loro vita a sostenere che o C o la morte e adesso dicono che C# è la via del futuro... :rolleyes: usare C++ no eh? ah lo usa già KDE :asd:
Ed IMHO non hanno tutti i torti, C# ha le medesime possibilità (o quasi) del C++, in più ha molte delle peculiaritù del Java ed almeno sotto Windows (per il momento) ha un'efficienza superiore grazie alla piattaforma .net ed al suo framework che (ancora una volta IMHO) è concettualmente meglio della JVM. ;)
Quando cominceranno il porting delle GTK dal C al C#? :stordita:
Ed IMHO non hanno tutti i torti, C# ha le medesime possibilità (o quasi) del C++, in più ha molte delle peculiaritù del Java ed almeno sotto Windows (per il momento) ha un'efficienza superiore grazie alla piattaforma .net ed al suo framework che (ancora una volta IMHO) è concettualmente meglio della JVM. ;)
avrei qualcosa da ridire a riguardo... causerebbe un notevole decadimento delle prestazioni allo stato attuale. IMHO i tempi non sono ancora maturi. che il framework .NET sia concettualmente meglio di java è tutto da verificare.. al momento hanno un GC migliore, ma nella prossima versione di java cambia ;)
Quando cominceranno il porting delle GTK dal C al C#? :stordita:
GTK#? mai sentito nominare? :read:
GTK#? mai sentito nominare? :read:
Gtk# è solo un wrapper per poter usare gtk, che restano scritte in C, anche da C#.
ciao ;)
Gtk# è solo un wrapper per poter usare gtk, che restano scritte in C, anche da C#.
ciao ;)
ah sì? sai non me ne intendo di gnomerie :asd: :)
Vash1986
20-07-2006, 12:37
Ed IMHO non hanno tutti i torti, C# ha le medesime possibilità (o quasi) del C++, in più ha molte delle peculiaritù del Java ed almeno sotto Windows (per il momento) ha un'efficienza superiore grazie alla piattaforma .net ed al suo framework che (ancora una volta IMHO) è concettualmente meglio della JVM. ;)
Quando cominceranno il porting delle GTK dal C al C#? :stordita:
non c'è dubbio che il framework è pensato molto ma molto meglio della virtual machine (per certe cose è molto più veloce ed efficiente)
se anche su linux ci fosse la possibilità di eseguire programmi .net con la stessa efficienza che su windows, allora direi che il C# sarebbe un signor linguaggio
rimane però il fatto che il C per calcolare 500 volte pi greco ha impiegato un quarto del tempo del C#... quindi al di là di procedure e oggetti c'è un collo di bottiglia prestazionale da qualche parte (forse il runtime del framework).
non c'è dubbio che il framework è pensato molto ma molto meglio della virtual machine (per certe cose è molto più veloce ed efficiente)
se anche su linux ci fosse la possibilità di eseguire programmi .net con la stessa efficienza che su windows, allora direi che il C# sarebbe un signor linguaggio
considera però che java è più portabile, .NET è pensato per architetture x86 limite che java non ha. è per questo che riesce a essere più efficiente (anche se il divario non mi sembra mica tanto evidente).
C# è già un signor linguaggio! lo considero il miglior linguaggio al momento... solo non mi piace l'implementazione che gli è stata data nel framework .NET :( trovo molto più ordinato e chiaro lo stile java (sono gusti eh!)
tomminno
20-07-2006, 22:05
considera però che java è più portabile, .NET è pensato per architetture x86 limite che java non ha. è per questo che riesce a essere più efficiente (anche se il divario non mi sembra mica tanto evidente).
C# è già un signor linguaggio! lo considero il miglior linguaggio al momento... solo non mi piace l'implementazione che gli è stata data nel framework .NET :( trovo molto più ordinato e chiaro lo stile java (sono gusti eh!)
Con mono puoi far girare C# su altre architetture oltre all'x86 e anche restando sul .NET il compact framework lo si può utilizzare su tutte le architetture per cui è disponibile WinCE.
Vash1986
20-07-2006, 22:32
Ricordate il doppio ciclo for per fare miliardi di iterazioni?
int main()
{
int i, j, n;
for ( i = 0; i < 1000000; i++ )
for ( j = 0; j < 1000; j++ )
n = 0;
return 0;
}
Prima qualcuno aveva detto che sarebbe stato interessante confrontare il codice asm. Beh ecco qui i due diversi codici, io non ne capisco una mazza :P
gcc -S prova.o
.file "prova.c"
gcc2_compiled.:
___gnu_compiled_c:
.def ___main; .scl 2; .type 32; .endef
.text
.align 4
.globl _main
.def _main; .scl 2; .type 32; .endef
_main:
pushl %ebp
movl %esp,%ebp
subl $24,%esp
call ___main
movl $0,-4(%ebp)
.p2align 4,,7
L3:
cmpl $999999,-4(%ebp)
jle L6
jmp L4
.p2align 4,,7
L6:
nop
movl $0,-8(%ebp)
.p2align 4,,7
L7:
cmpl $999,-8(%ebp)
jle L10
jmp L5
.p2align 4,,7
L10:
movl $0,-12(%ebp)
L9:
incl -8(%ebp)
jmp L7
.p2align 4,,7
L8:
L5:
incl -4(%ebp)
jmp L3
.p2align 4,,7
L4:
xorl %eax,%eax
jmp L2
.p2align 4,,7
L2:
leave
ret
gcc -S prova.c -O3
.file "prova.c"
gcc2_compiled.:
___gnu_compiled_c:
.def ___main; .scl 2; .type 32; .endef
.text
.align 4
.globl _main
.def _main; .scl 2; .type 32; .endef
_main:
pushl %ebp
movl %esp,%ebp
subl $8,%esp
call ___main
xorl %eax,%eax
.p2align 4,,7
L6:
incl %eax
movl $999,%ecx
.p2align 4,,7
L10:
decl %ecx
jns L10
cmpl $999999,%eax
jle L6
xorl %eax,%eax
leave
ret
ilsensine
21-07-2006, 08:12
gcc -S prova.c -O3
.file "prova.c"
gcc2_compiled.:
___gnu_compiled_c:
.def ___main; .scl 2; .type 32; .endef
.text
.align 4
.globl _main
.def _main; .scl 2; .type 32; .endef
_main:
pushl %ebp
movl %esp,%ebp
subl $8,%esp
call ___main
xorl %eax,%eax
.p2align 4,,7
L6:
incl %eax
movl $999,%ecx
.p2align 4,,7
L10:
decl %ecx
jns L10
cmpl $999999,%eax
jle L6
xorl %eax,%eax
leave
ret
Il tuo gcc è un pò tonto ;)
Il mio (4.1.qualcosa) genera semplicemente questo:
gcc -S -o prova.S prova.c -O
.file "prova.c"
.text
.globl main
.type main, @function
main:
leal 4(%esp), %ecx
andl $-16, %esp
pushl -4(%ecx)
pushl %ebp
movl %esp, %ebp
pushl %ecx
movl $0, %eax
popl %ecx
popl %ebp
leal -4(%ecx), %esp
ret
.size main, .-main
.ident "GCC: (GNU) 4.1.2 20060715 (prerelease) (Debian 4.1.1-9)"
.section .note.GNU-stack,"",@progbits
...ed è ancora un pò tonto, visto che potrebbe eliminare anche il codice di prologo/epilogo :D
Prova questo con il GCC 4.1 e vediamo cosa viene fuori:
int main()
{
int i, j, n;
for ( i = 0; i < 1000000; i++ )
for ( j = 0; j < 1000; j++ )
n = i+j;
return 0;
}
ilsensine
21-07-2006, 08:27
Stessa cosa :)
Se invece sostituisco return 0 con return n, viene fuori questo:
.file "prova.c"
.text
.globl main
.type main, @function
main:
leal 4(%esp), %ecx
andl $-16, %esp
pushl -4(%ecx)
pushl %ebp
movl %esp, %ebp
pushl %ecx
movl $1000998, %eax
popl %ecx
popl %ebp
leal -4(%ecx), %esp
ret
.size main, .-main
.ident "GCC: (GNU) 4.1.2 20060715 (prerelease) (Debian 4.1.1-9)"
.section .note.GNU-stack,"",@progbits
...il gcc ha semplicemente calcolato l'ultimo valore di n!
...il gcc ha semplicemente calcolato l'ultimo valore di n!
Spettacolare !!! :sofico:
Prova un po' a mettere un printf("%d", i+j);
Voglio vedere sa fa il loop unrolling...
Vash1986
21-07-2006, 09:34
Il tuo gcc è un pò tonto ;)
è il mingw, port per windows del gcc (3?)
Sapete qualche guida per linguaggio assembly? Mi dà un enorme fastidio non riuscire a decifrare sta roba :help:
ilsensine
21-07-2006, 09:35
Spettacolare !!! :sofico:
Prova un po' a mettere un printf("%d", i+j);
Voglio vedere sa fa il loop unrolling...
Guarda questo:
int main()
{
int i, j, n = 0;
for ( i = 0; i < 1000000; i++ )
for ( j = 0; j < 1000; j++ )
n += i+j;
return n;
}
Sappiamo bene che n è un valore determinato, in teoria calcolabile durante la stessa compilazione. Il compilatore però non lo sa (in ogni caso il calcolo non è immediato); ciò nonostante, riesce ad eliminare il loop interno!
Infatti il codice è equivalente a:
for ( i = 0; i < 1000000; i++ )
n += 1000*i+499500; // 449500 = (999*1000)/2;
E questo è ciò che il gcc tira fuori!
.file "prova.c"
.text
.globl main
.type main, @function
main:
leal 4(%esp), %ecx
andl $-16, %esp
pushl -4(%ecx)
pushl %ebp
movl %esp, %ebp
pushl %ecx
movl $0, %eax
movl $0, %edx
movl $0, %ecx
.L2:
addl %edx, %eax
leal 499500(%eax,%ecx), %eax
incl %edx
addl $999, %ecx
cmpl $1000000, %edx
jne .L2
popl %ecx
popl %ebp
leal -4(%ecx), %esp
ret
.size main, .-main
.ident "GCC: (GNU) 4.1.2 20060715 (prerelease) (Debian 4.1.1-9)"
.section .note.GNU-stack,"",@progbits
- ecx contiene i*999 (inutile calcolare la moltiplicazione ogni volta: basta aggiungere 999 ad ogni ciclo! ). E' buffo che il gcc non ha "visto" 1000*i, ma 999*i+i.
- eax contiene n; edx contiene i
Mamma mia...hanno ottimizzato anche prologo ed epilogo :eek:
Vash1986
21-07-2006, 10:03
Ho fatto na scemenza... usavo una vecchia versione del DevCpp per windows, con un gcc del 2000 ^_^
Ora invece ho scaricato Code::Blocks con il gcc 3.4.4 :D
Cmq ho inserito nella PATH del prompt dei comandi la cartella con il gcc ma devo dire che windows è proprio uno schifo per certe cose rispetto a linux :rolleyes:
Vash1986
21-07-2006, 13:02
Un'ultima domanda. Mi è sembrato di capire che in questi casi in cui ci sono cicli che possono essere evitati xkè fan sempre la stessa cosa, interviene il compilatore ottimizzando il codice.
Ma le ottimizzazioni vengono fatte solo su "disattenzioni" del programmatore che scrive del codice inutile (tipo i 2 miliardi di iterazioni del mio programma) o anche un codice pulito e compatto al 100% è soggetto a qualche tipo di ottimizzazione di basso livello?
ilsensine
21-07-2006, 13:30
Ma le ottimizzazioni vengono fatte solo su "disattenzioni" del programmatore che scrive del codice inutile (tipo i 2 miliardi di iterazioni del mio programma) o anche un codice pulito e compatto al 100% è soggetto a qualche tipo di ottimizzazione di basso livello?
Il programmatore in primis deve evitare di attentare al cuoio capelluto di chi leggerà il programma (eventualmente lui stesso, dopo un pò di mesi).
Ad esempio questo:
for ( i = 0; i < 1000000; i++ )
n += 1000*i+499500;
apparentemente è molto più veloce di questo:
for ( i = 0; i < 1000000; i++ )
for ( j = 0; j < 1000; j++ )
n += i+j;
}
Invece, il compilatore riesce a ottimizzare il secondo caso riportandolo in pratica nel primo (l'unica differenza è il 1000*i= 999*i+i). Sfido chiunque però a dirmi a una prima occhiata cosa faccia il primo codice ;)
Vash1986
21-07-2006, 14:17
Mi sembra di capire che le ottimizzazioni da un lato aggiustano ciò che il programmatore non è riuscito a fare in maniera abbastanza ottimale e compatta, e dall'altro lato ti permettono di fare codice meglio leggibile senza sacrificare le prestazioni, giusto?
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.