crossMark: un bench per Mac e Win

[riaw]

sembrano più congruenti?
da quel test sembra che un p4 1.8 mobile è 5 volte più veloce di un g4 1.67 e 10 volte più veloce di un xp1400........

[Cecilia76]

Non è un P4 mobile è un Pentium-M (centrino) che appunto dovrebbe andare come un 3.0 Ghz.
E' vero tuttavia che i valori su G4 sono bassi.

[cdimauro]

I benchmark sintetici non servono a nulla: vanno testate le applicazioni reali (FFT -> JPEG, Wavelet -> JPEG2000, Noise generator -> Filtro audio o video, ecc.).

Comunque ecco i risultati ottenuti su un Athlon64 3000+ (2Ghz) su Linux Red Hat Fedora Core 2 per x86-64.

Compilando il sorgente senza alcuna ottimizzazione (g++ crossMark.cpp), per x86 a 32 bit:

testing wavelet transform... 2.33 sec.
testing fourier transform... 110.4 sec.
testing noise generation... 0.97 sec.
average computation time... 37.9 sec.

performance score: 5.27704

Compilando il sorgente con alcune ottimizzazioni attivate e scegliendo Athlon-XP come architettura target (g++ -march=athlon-xp -O2 -ffast-math -funroll-all-loops -ftracer crossMark.cpp), per x86 a 32 bit:

testing wavelet transform... 0.98 sec.
testing fourier transform... 39.09 sec.
testing noise generation... 1.02 sec.
average computation time... 13.6967 sec.

performance score: 14.6021

Compilando il sorgente per Athlon64 senza alcuna ottimizzazione (g++ -march=athlon64 crossMark.cpp), per x86-64 a 64 bit:

testing wavelet transform... 2.28 sec.
testing fourier transform... 78.19 sec.
testing noise generation... 1.05 sec.
average computation time... 27.1733 sec.

performance score: 7.36016

Compilando il sorgente per Athlon64 con alcune ottimizzazioni (g++ -march=athlon64 -O2 -ffast-math -funroll-all-loops -ftracer crossMark.cpp), per x86-64 a 64 bit:

testing wavelet transform... 1 sec.
testing fourier transform... 38.97 sec.
testing noise generation... 1 sec.
average computation time... 13.6567 sec.

performance score: 14.6449

[cdimauro]

Originariamente inviato da Cecilia76
La differenza sostanziale di prestazioni si fa sentire solo sull'FFT: sotto OS X è spaventosamente più rapida. Per gli altri bench (wavelet e random) le cose sono più congruenti. Purtroppo però non è un baco: il codice dell'FFT è un codice molto studiato ed usato professionalmente tante volte. Credo che sia qualcosa legato all'architettura RISC o CISC.

Non credo. Comunque esistono diverse implementazioni dell'FFT: quella di quei sorgenti è una delle tante.
Ho notato che fai ampio uso di double nel codice: come mai? I dati sono single e non double...

In ogni caso, sto preparando una nuova versione senza FFT in modo da poter fare un indice di confronto tra i vari sistemi e lo distribuirò anche per Linux.

Con Linux ho già provato io: basta ricompilare...

L'estimated cpu freq non deve necessariamente rispettare il clock del processore: è un valore relativo da confrontare con altre piattaforme: ad esempio sul mio centrino a 1.8 mi dice che la freq è 2.9/3 che più o meno corrisponde a quella di un p4.

La frequenza con Linux non appare: forse l'hai eliminata?

[Gold2004]

Esimii programmatori, illuminatemi, cos'e' un FFT (ma anche un wavelet, che dal nome sempra una applet di quelle inutili che sit engono sul desktop^^)??

Grazie mille.

Saluti

[edoardopost]

Devo copiare i valori dalla finestra a mano per inserirli qui ?

[Myname]

Uhm...allora o cancello la vecchia discussione, oppure le unisco per dare una sequenza logica...
Cecilia scegli.
Myname

[Hocico]

Il tuo bench test da risultati scarsi sul G4, nel test della trasformata di fourier, perchè in questi tipi di calcolo generalmente viene usata Altivec.

Il G4 nel calcolo FP puro va meno bene a causa dell'unica unità FP presente.

Nei test di distributed.NET ottimizzati per Altivec un G4 a 800 Mhz rivaleggia con un P4 a 2.3 Ghz...

[riaw]

Originariamente inviato da Hocico
Il tuo bench test da risultati scarsi sul G4, nel test della trasformata di fourier, perchè in questi tipi di calcolo generalmente viene usata Altivec.

Il G4 nel calcolo FP puro va meno bene a causa dell'unica unità FP presente.

Nei test di distributed.NET ottimizzati per Altivec un G4 a 800 Mhz rivaleggia con un P4 a 2.3 Ghz...

non esiste il p4 2.3.....
come hanno fatto a compararlo a un g4 800?

[Hocico]

Originariamente inviato da riaw
non esiste il p4 2.3.....
come hanno fatto a compararlo a un g4 800?

Mi correggo, ricordavo male, a oltre 3 Ghz...

Links:

http://n0cgi.distributed.net/speed/q...&contest=rc572
http://n0cgi.distributed.net/speed/q...&contest=rc572

[Myname]

Ok unisco nella nuova discussione...
Myname

[Cecilia76]

Grazie Myname,

scusa se non ti rispondo ma ho la febbre e sono a letto.

1. Ho eliminato il valore della cpu freq perchè creava molta confusione.
Basta creare una scala con lo score ottenuto.
2. In ogni caso l'FFT è troppo problematica. Domani rilascierò una
versione senza FFT.
3. FFT e wavelet sono delle trasformate per portare dei dati da un
dominio ad un altro. Si usano anche nell'MP3 e nella compressione
JPEG.
4. Nella prossima versione salverò i dati in un file, ok?

Grazie a tutti, C.

[cdimauro]

Originariamente inviato da Hocico
Il tuo bench test da risultati scarsi sul G4, nel test della trasformata di fourier, perchè in questi tipi di calcolo generalmente viene usata Altivec.

Il G4 nel calcolo FP puro va meno bene a causa dell'unica unità FP presente.

Non credo che venga utilizzato l'Altivec compilando questi sorgenti né le estensioni SIMD per gli altri processori: molto probabilmente verrà usata esclusivamente l'FPU.

Nei test di distributed.NET ottimizzati per Altivec un G4 a 800 Mhz rivaleggia con un P4 a 2.3 Ghz...

Questo non vuol dire nulla a livello generale. Se prendiamo Maya, anche un vecchio Athlon XP ha la meglio su un G5. Ma questo si verifica in UN contesto, appunto.

Questo thread è stato aperto su alcuni SPECIFICI algoritmi: atteniamoci a questi.

[cdimauro]

Originariamente inviato da Cecilia76
2. In ogni caso l'FFT è troppo problematica. Domani rilascierò una
versione senza FFT.

Diciamo che l'implementazione non è delle migliori.

Personalmente farei un paio di cose:

1) eliminerei il C++ come linguaggio, che per lo scopo del progetto è ridondante: meglio usare il C, visto che l'obiettivo è quello di testare degli algoritmi "classici". Questo permetterà di focalizzare l'attenzione su alcuni dettagli implementativi;

2) cercherei in qualche testo di analisi numerica o calcolo numerico un'implementazione più efficiente di quella che hai usato.

Poi, avendo tempo, potresti inserire anche qualche test con la DCT, visto che attualmente è la trasformata più usata (dal JPEG all'MPEG4, ecc.).
Anche di questa ne esistono diverse implementazioni (ce n'è una che sacrifica un po' la precisione, ma utilizza 11 moltiplicazioni anziché le canoniche 12, ad esempio).

Per le wavelet: ce ne sono centinaia , ma sarebbe interessante implementare la 9/7 (irreversibile) e la 5/3 (reversibile) che sono usate da JPEG 2000 e Motion JPEG 2000.

In generale: FFT, Wavelet, DCT, noise generator, ecc. si possono implementare non solo coi float (e in questo sarebbe preferibile adottare soluzioni che utilizzano solamente la precisione singola o quella doppia, senza "mischiare" i due tipi di dati), ma anche con aritmetica intera fixed point.

Fermo restando che, a mio avviso, questo tipo di benchmark non serve a nulla se non inserito in un contesto specifico.

[Cecilia76]

Grazie per i suggerimenti.
L'implementazione che hai visto è la seconda: la prima era sicuramente più efficiente ma dava risultati mostruosamente diversi tra G4 e Pentium-M.
Ho usato tanti testi di analisi numerica per l'implementazione; in ogni caso entrambe sono codice già usato commercialmente. Il riferimento è comunque Numerical recipes in C.
Se in ogni caso hai una implementazione migliore sarei felice di usarla.
Per quanto riguarda la DCT: non possiedo una implementazione; mi indichi un posto dove scaricarla.
Il C++ qui è usato solo per l'estensione del file effettivamente è codice in C.
Ho scelto di usare float e non aritmetica intera proprio per vedere come rispondono i processori con questo tipo di calcolo.

Grazie ancora, C.

[cdimauro]

Originariamente inviato da Cecilia76
Grazie per i suggerimenti.
L'implementazione che hai visto è la seconda: la prima era sicuramente più efficiente ma dava risultati mostruosamente diversi tra G4 e Pentium-M.
Ho usato tanti testi di analisi numerica per l'implementazione; in ogni caso entrambe sono codice già usato commercialmente. Il riferimento è comunque Numerical recipes in C.

Ho capito. Numerical Recipes, però, è più orientato a chi vuol capire come funziona (agli studenti).

Se in ogni caso hai una implementazione migliore sarei felice di usarla.

Francamente è passata una decina d'anni da quando mi sono interessato all'FFT, per cui adesso non ricordo proprio...
Se sei ancora studente all'università, puoi controllare in biblioteca i test esistenti a riguardo, e le riviste scientifiche disponibili (ACM e IEEE su tutte: sono un'autentica miniera! )

Per quanto riguarda la DCT: non possiedo una implementazione; mi indichi un posto dove scaricarla.

La trovi dentro i sorgenti di JPEG... Chiaramente è quella bidimensionale, che funziona su blocchi di dati 8x8, però puoi tirare fuori anche la versione monodimensionale, che funziona sempre su gruppi di 8 dati.
Per la versione "generale" (n dati anziché sempre e soltanto 8), dovresti consultare le fonti di cui sopra.

Il C++ qui è usato solo per l'estensione del file effettivamente è codice in C.

Maggiormente sì, ma hai usato abbastanza alcuni costrutti del C++. Se puoi, "torna" al C.

Ho scelto di usare float e non aritmetica intera proprio per vedere come rispondono i processori con questo tipo di calcolo.

OK. Allora ti consiglio di non mischiare valori in double e single: usa soltanto uno dei due.
Anzi, potresti dichiarare con un typedef il tipo di dato da usare, così da rendere semplice la compilazione e i test con l'uno o l'altro tipo di dato.

Grazie ancora, C.

Di niente.

Ciao