Test velocistico: 5M iterazioni C/C#/Java

[sirus]

Originariamente inviato da Vash1986

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 ).

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.

[cionci]

Originariamente inviato da sirus

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 ).

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]

Originariamente inviato da cionci

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++?

[k0nt3]

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

[Vash1986]

Originariamente inviato da k0nt3

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.

[k0nt3]

Originariamente inviato da Vash1986

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

[Vash1986]

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?

[k0nt3]

Originariamente inviato da Vash1986

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

Originariamente inviato da Vash1986

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... usare C++ no eh? ah lo usa già KDE

Originariamente inviato da Vash1986

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.

Originariamente inviato da Vash1986

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]

Originariamente inviato da k0nt3

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).

[cionci]

Originariamente inviato da Vash1986

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++
In realtà in C++ ci si trova negli stessi problemi del C, anche se sono sicuramente minori se si "programma bene"...

[Vash1986]

Originariamente inviato da cionci

Con un garbage collector li puoi evitare anche con il C++
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

[k0nt3]

Originariamente inviato da Vash1986

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

[cionci]

Originariamente inviato da Vash1986

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

[a2000.1]

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/sez...oni-meteo.html

http://www.thocp.net/hardware/nec_ess.htm

http://www.hpfpc.org/index-E.html

[cionci]

a2000: non è che hai sbagliato thread ?

[Vash1986]

Originariamente inviato da cionci

a2000: non è che hai sbagliato thread ?

magari si scopre che il software che gira su quel pc è fatto in Java

[a2000.1]

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

[a2000.1]

Java, nuova scossa di terremoto
torna la paura dello tsunami

http://www.repubblica.it/2006/07/sez...e-tsunami.html

[Vash1986]

Originariamente inviato da a2000.1

Software: for the most part Fortran using MPI

...

Java, nuova scossa di terremoto

ahah

[sirus]

Originariamente inviato da k0nt3

...
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... usare C++ no eh? ah lo usa già KDE

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#?