[C/C++] Intel Centrino batte AMD64 con gli array

[andreaM]

Ciao. Chiedo gentilmente opinione e consiglio a tutti.

Questo programma di esempio gira con tempi strani e, soprattutto porta alla vittoria di un centrino 1.6MHz (Dothan) contro un AMD64-3000+(Winchester). Vi inviterei a provare. Il codice lo trovate in fondo.

Riassunto veloce:

- array 13x13, ma la dimensione non è vincolante.
- le matrici sono int e unsigned char
- vengono inizializzate 100milioni di volte

Le inizializzazioni sono di due tipi:

- una percorre la matrice da sinistra a destra
- l'altra dall'alto verso il basso

Compilo su un Centrino 1.6 con gcc 3.3.5 ed opzioni -03 -g0 e si ottengono i seguenti tempi:

Starting up-down mode INT...
Elapsed : 25 secs.

Starting up-down mode UCHAR...
Elapsed : 24 secs.

Starting left-right mode INT...
Elapsed : 34 secs.

Starting left-right mode UCHAR...
Elapsed : 34 secs.

Allora, è sensato che percorrere dall'alto cerso il basso la matrice sia più conveniente, poichè le locazioni di memoria vengono percorse in modo contiguo ed ogni load in cache si porta dietro almeno una parola (giusto?).

Comincia non tornare nella scarsa o nessuna differenza tra l'uso di int e uchar, che dovrebbero essere indirizzate a 16 e 8 bit rispettivamente.

Non mi torna per niente che questo programmino giri più lento su un AMD64-3000+.

Ditemi voi cosa ne pensate.

Grazie e ciao!

Andrea


Codice:

#include <iostream>
#include <cstdlib>

#define K 12
#define BOUND 100000000

using namespace std;

int main(int argc, char *argv[])
{

 unsigned char matrixC [K+1][K+1];
 int matrixI [K+1][K+1];
 
  unsigned long startTime;
  unsigned long finishTime;
  
  /* 
  	In tutte le matrici non si fa altro che assegnare un valore 
  	fissato per ogni elemento un numero di volte pari a BOUND
  */
 
  
  cout << "\n\nStarting up-down mode INT..." << endl;  
  startTime = time(0);
  
  for (int M = 0; M < BOUND; M++)
  	for (int j = 0; j <= K; j++)
  		for (int i = 0; i <=K; i++)
  			matrixI[i][j] = 1;
  			
  finishTime = time(0);  
  cout << "Elapsed : " << finishTime-startTime << " secs." << endl;
  
  
  
  cout << "\n\nStarting up-down mode UCHAR..." << endl;  
  startTime = time(0);
  
  for (int M = 0; M < BOUND; M++)
  	for (int j = 0; j <= K; j++)
  		for (int i = 0; i <=K; i++)
  			matrixC[i][j] = 2;
  			
  finishTime = time(0);  
  cout << "Elapsed : " << finishTime-startTime << " secs." << endl;
  

 
  cout << "\nStarting left-right mode INT..." << endl;  
  startTime = time(0);
  
  for (int M = 0; M < BOUND; M++)
  	for (int i = 0; i <= K; i++)
  		for (int j = 0; j <=K; j++)
  			matrixI[i][j] = 3;
  			
  finishTime = time(0);
  cout << "Elapsed : " << finishTime-startTime << " secs." << endl; 
  
  
   cout << "\nStarting left-right mode UCHAR..." << endl;  
  startTime = time(0);
  
  for (int M = 0; M < BOUND; M++)
  	for (int i = 0; i <= K; i++)
  		for (int j = 0; j <=K; j++)
  			matrixC[i][j] = 4;
  			
  finishTime = time(0);  
  cout << "Elapsed : " << finishTime-startTime << " secs." << endl;
  

  return EXIT_SUCCESS;
}

[Fenomeno85]

devi provare a compilare ottimizzando il codice per ogni piattaforma, li capisci realmente il limite della cpu.

~§~ Sempre E Solo Lei ~§~

[andreaM]

Originariamente inviato da Fenomeno85

devi provare a compilare ottimizzando il codice per ogni piattaforma, li capisci realmente il limite della cpu.

~§~ Sempre E Solo Lei ~§~

Innanzi tutto grazie per aver risposto.
Su AMD64 ho provato a dare delle opzioni a gcc mirate proprio a questo, del tipo:

-march , -mcpu , -m32 o m64 (una alla volta) per legare l'eseguibile all'architettura sottostante

eppure non è cambiato proprio nulla. Un idea?

[Fenomeno85]

per intel c'è il compilatore sui volendo ma ti costa un botto, poi prova a fare ottimizzione migliore che se non erro è -o3

~§~ Sempre E Solo Lei ~§~

[andreaM]

Originariamente inviato da Fenomeno85

per intel c'è il compilatore sui volendo ma ti costa un botto, poi prova a fare ottimizzione migliore che se non erro è -o3

~§~ Sempre E Solo Lei ~§~

Compilo su entrambe le architetture sempre con -O3 -g0 : su Intel Centrino va come spiegato sopra, mentre su AMD64 rallenta.

Io non sono sicuro che si tratti di un problema di compilazione non ottimizata. Infatti ci sono altri tipi di programmi che ho realizzato, meno sensibili all'indirizzamento e più esosi di clock: lì le cose cambiano, eppure la piattaforma è la stessa...

Guarda è un bel rompicapo.

Ciao.

[cionci]

Intanto le matrici sono 13x13 Se il ciclo lo fai partire da zero fino <= K sono 13...
E' possibilissimo che il P-M si più veloce dell'Athlon 64...non ci vedo niente di strano... L'alu del Pentium 3 è sempre stata molto efficiente...

Il compilatore probabilmente alloca i char allineandoli ai 32 bit...di conseguenza la matrice di char occupa la stessa dimensione di una matrice di int...
Questo perchè non è così agevole per le CPU moderne accedere solamente ad uno dei vari byte di una locazione a 32 bit...

[andreaM]

Originariamente inviato da cionci

Intanto le matrici sono 13x13 Se il ciclo lo fai partire da zero fino <= K sono 13...

Ehm, già... La frenesia del cut&paste! sorry.

E' possibilissimo che il P-M si più veloce dell'Athlon 64...non ci vedo niente di strano... L'alu del Pentium 3 è sempre stata molto efficiente...

Si impara sempre qualcosa... Stessa faccenda con i Pentium4?

Il compilatore probabilmente alloca i char allineandoli ai 32 bit...di conseguenza la matrice di char occupa la stessa dimensione di una matrice di int...
Questo perchè non è così agevole per le CPU moderne accedere solamente ad uno dei vari byte di una locazione a 32 bit...

Questo lo sospettavo, anche se mi aspettavo di poter allineare a 32 bit due coppie di int e a 64 bit 4coppie...

Grazie comunque per la risposta.
Ciao.

[cionci]

Un int è già a 32 bit...non c'è bisogno di allinearlo...

Il P4 suppongo che vada più lento...anche se bisogna sempre vedere la frequenza...

[andreaM]

Originariamente inviato da cionci

Un int è già a 32 bit...non c'è bisogno di allinearlo...

In realtà mi riferivo allo standard ANSI del C++, che prevedeva:

char a 8 bit
int a 16 bit
float a 32 bit
double a 64 bit

(per questo speravo quanto ti ho detto)
ovviamente, però, i progettisti dei vari compilatori hanno fatto delle scelte diverse.

Il P4 suppongo che vada più lento...anche se bisogna sempre vedere la frequenza...

Se hai un po' di pazienza & tempo, me la chiariresti questa cosa? Il fatto che una ALU più efficente faccia la differenza su un programma di questo tipo non lo capisco.

Pensavo piuttosto alla differenza di cache tra i due processori della prova: un Intel con core Banias ha 2MB di L2, mentre lo AMD Winchester ne ha 512KB.
Non potrebbe essere?

Ciao.

Andrea

[cionci]

Originariamente inviato da andreaM

In realtà mi riferivo allo standard ANSI del C++, che prevedeva:

Non credo che lo stadard imponga quelle dimensioni...
Solitamente l'int è pari alla grandezza del registro della ALU...

Questo programma sicuramente non risentirà della cache L2, visto che girerà sempre sulla L1...

Gli accessi alla RAM quindi hanno una latenza molto bassa...
Per ogni inizializzazione dovrai fare un solo accesso alla cache (suppongo solo uno visto che il vettore è allocato staticamente), ma dovrai fare una prodotto per calcolare l'indirizzo della linea (si fa con la ALU), un'altra somma per calcolare la posizione del dato nella linea (questa operazione si fa con la AGU), l'accesso alla cache, e poi per ogni for più interno: un incremento, un confronto ed una jump condizionata)... Sono 1 operazione AGU e 4 ALU per ogni accesso alla cache... Quindi suppongo che siano le 5 operazioni a dare un contributo superiore a quello dell'accesso alla cache...

[andreaM]

Originariamente inviato da andreaM

In realtà mi riferivo allo standard ANSI del C++, che prevedeva:

char a 8 bit
int a 16 bit
float a 32 bit
double a 64 bit

(Qui mi auto-quoto ) , dimenticavo l'uso di sizeof in C++.. da cui ho appena scoperto che in gcc si ha che

char 1 byte (come ANSI)
int 4 byte
float 4 byte (come ANSI)
double 8 byte (come ANSI)

[andreaM]

Originariamente inviato da cionci

Non credo che lo stadard imponga quelle dimensioni...
Solitamente l'int è pari alla grandezza del registro della ALU...

Per questo citavo il libro di Helbert Schildt.. comunque ANSI non lo imponeva, le raccomandava solo come minime.

Questo programma sicuramente non risentirà della cache L2, visto che girerà sempre sulla L1...

Gli accessi alla RAM quindi hanno una latenza molto bassa...
Per ogni inizializzazione dovrai fare un solo accesso alla cache (suppongo solo uno visto che il vettore è allocato staticamente), ma dovrai fare una somma per calcolare l'indirizzo della linea, un'altra somma per calcolare la posizione del dato nella linea (queste operazioni si fanno con la AGU), l'accesso alla cache, e poi per ogni for più interno: un incremento, un confronto ed una jump condizionata)... Sono 2 operazioni AGU e 3 ALU per ogni accesso alla cache... Quindi suppongo che siano le 5 operazioni a dare un contributo superiore a quello dell'accesso alla cache...

Perfetto, Chiaro. Grazie.

[cdimauro]

Le matrici sono piccole e stanno tutte nella cache L1, per cui può darsi che in questo caso la maggior efficienza dell'accesso alla cache dei Pentium-M faccia la differenza.

I char in questo dovrebbero occupare comunque 1 byte.

[cionci]

Ora che ci penso con -O3 ci sta che faccia anche il loop unrolling...in questo caso ci sarebbero solo accessi alla L1...

Originariamente inviato da cdimauro

I char in questo dovrebbero occupare comunque 1 byte.

Allora come spieghi il fatto che abbiano le stesse prestazioni ?

[cdimauro]

Proprio perché i dati stanno tutti nella cache: una volta caricati, accedere a un byte o a un valore a 32 bit è indifferente per il processore.

[cionci]

Originariamente inviato da cdimauro

Proprio perché i dati stanno tutti nella cache: una volta caricati, accedere a un byte o a un valore a 32 bit è indifferente per il processore.

E' vero...che testa

[andreaM]

Originariamente inviato da cdimauro

Proprio perché i dati stanno tutti nella cache: una volta caricati, accedere a un byte o a un valore a 32 bit è indifferente per il processore.

Fatemi capire bene:

- questo tipo di programma porta la matrice in L1 e, ad ogni inizializzazione, la ALU calcola la posizione dell'elemento in cache.

- per questo motivo usare char, short int o int non dovrebbe avere impatto sulle prestazione (anche se un po' invece succede). A patto che la matrice non diventi troppo grande e serva utilizzare anche la L2.

- il Centrino va più veloce perchè ha una ALU più efficiente: su questo cdimauro concorda?

Ciao.

[cionci]

Secondo cdimauro la cache L1 del P-M è più efficiente...però sarei d'accordo su questo se con -O3 il compilatore facesse il loop unrolling...in tal caso il tutto si riduce ai soli accessi alla L1...

La differenza non c'è fra int e char perchè il protocollo di accesso alla L1 è identico sia che si voglia recuperare un int che un char...

[andreaM]

Originariamente inviato da cionci

Secondo cdimauro la cache L1 del P-M è più efficiente...però sarei d'accordo su questo se con -O3 il compilatore facesse il loop unrolling...in tal caso il tutto si riduce ai soli accessi alla L1...

Secondo il manuale gcc il loop unrolling si abilita con le seguenti opzioni di ottimizzazione:


-funroll-loops
-funroll-all-loops


che però NON sono abilitate con nessuna opzione -Ox. Perciò le prestazioni misurate non beneficiano del loop unrolling.

[DioBrando]

Originariamente inviato da andreaM

Pensavo piuttosto alla differenza di cache tra i due processori della prova: un Intel con core Banias ha 2MB di L2, mentre lo AMD Winchester ne ha 512KB.
Non potrebbe essere?

Ciao.

Andrea

solo una precisazione, il core Banias ha un 1 MB di cache L2

ma è cmq il doppio rispetto all'A64