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

View Full Version : [C/C++] Intel Centrino batte AMD64 con gli array

andreaM

09-09-2005, 11:35

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+. :confused:

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

09-09-2005, 14:16

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

~§~ Sempre E Solo Lei ~§~

andreaM

09-09-2005, 14:45

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

09-09-2005, 15:03

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

09-09-2005, 15:19

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. :muro:

Ciao.

cionci

09-09-2005, 17:29

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

09-09-2005, 17:38

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

09-09-2005, 17:41

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

09-09-2005, 21:39

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

09-09-2005, 22:05

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

09-09-2005, 22:08

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 :D ) , 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

09-09-2005, 22:11

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

10-09-2005, 08:42

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

10-09-2005, 08:50

Ora che ci penso con -O3 ci sta che faccia anche il loop unrolling...in questo caso ci sarebbero solo accessi alla L1...
I char in questo dovrebbero occupare comunque 1 byte.
Allora come spieghi il fatto che abbiano le stesse prestazioni ?

cdimauro

12-09-2005, 09:45

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

12-09-2005, 09:50

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 :doh:

andreaM

12-09-2005, 12:51

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

12-09-2005, 13:11

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

12-09-2005, 14:08

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

12-09-2005, 17:11

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 :D

andreaM

12-09-2005, 17:53

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

ma è cmq il doppio rispetto all'A64 :D

Urca trottola... ho sbagliato. :doh: Ho un Dothan!

Ma i dati sulla cache son giusti: 32KB+32KB L1 e 2MB L2...

The3DProgrammer

12-09-2005, 18:14

fallo tu l'unroll ;)

ciauz

andreaM

12-09-2005, 19:09

fallo tu l'unroll ;)

ciauz

Uh? :confused: In che senso?

Comuque ho provato a compilare con le opzioni di unrolling: non cambia nulla. Anzi, up-down mode con gli int peggiora di un secondo...

Ciao!

cdimauro

13-09-2005, 11:38

- 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.
Con gli int si ha una leggera perdita di prestazioni perché i dati da caricare in cache sono il quadruplo rispetto ai char.
- il Centrino va più veloce perchè ha una ALU più efficiente: su questo cdimauro concorda?

Ciao.
No: le ALU degli Athlon/Athlon64 sono molto efficienti, quindi IMHO non è questo il problema.

La cache L1 e L2 dei Pentium-M, invece, hanno tempi di accesso migliori, per cui è questo che fa la differenza in questo programma. Sempre IMHO. ;)

andreaM

13-09-2005, 12:51

La cache L1 e L2 dei Pentium-M, invece, hanno tempi di accesso migliori, per cui è questo che fa la differenza in questo programma. Sempre IMHO. ;)

A questo punto voglio provare con qualche altra CPU... qualcuno mi può consigliare un processore con cache L1 ad alte prestazioni?

cdimauro

14-09-2005, 10:52

I P4 Willamette e NorthWood sono dotati di cache dati L1 con tempo di accesso di soli 2 cicli di clock: puoi provare con questi.

Questa cache è di soli 8KB, ma le matrici con cui lavori dovrebbero strarci tranquillamente.

The3DProgrammer

14-09-2005, 11:12

Uh? :confused: In che senso?

Comuque ho provato a compilare con le opzioni di unrolling: non cambia nulla. Anzi, up-down mode con gli int peggiora di un secondo...

Ciao!

il loop unrolling è una delle ottimizzazioni + basilari e allo stesso tempo + facili da realizzare. Invece di scrivere, ad es:

for(int i=0; i<100; i++)
v[i]=....

puoi scrivere

for(int i=0; i<100; i+=4){

v[i]=...
v[i+1]=...
v[i+2]=...
v[i+3]=....

}

Questo consente di sfruttare al max la pipeline, evitando di effettuare una branch prediction ad ogni loop (anke se essendo un salto all'indietro le BPU delle moderne CPU praticamente nn lo sbagliano mai ;)). Di conseguenza puoi adattare il tuo algoritmo da solo, questo ti consente anke di trovare il grado di unroll + performante.

ciauz

andreaM

14-09-2005, 11:27

Un grazie a cdimauro The3DProgrammer per i preziosi consigli. Ovviamente anche a cionci e la pazienza che ha avuto nello spiegare tutto...

Cercherò di sperimentare a breve quanto sugerito.

Ciao.

cionci

14-09-2005, 11:39

Interessante come, a seconda delle ottimizzazioni scelte, sul mio Athlon 64 3200+ i risultati cambino notevolmente:

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

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

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

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

Questo sopra con -march=pentium4 -O3

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

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

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

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

Questo sopra con -march=athlon64 -O3

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

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

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

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

Questo sopra con -march=386 -O3

Della serie: due codepath diversi non fanno alcuna differenza :muro:
E addirittura il risultato del test con ottimizzazione per 386 è in un caso migliore di quello ottimizzato per Athlon 64 !!!

cdimauro

14-09-2005, 12:24

Se è per questo con GCC4.0 la generazione del codice mi sembra peggiorata in alcuni casi rispetto al 3.x: basti vedere i risultati di FLOPS... :muro:

RaouL_BennetH

14-09-2005, 17:00

cionci

14-09-2005, 17:04

Infatti quello hce ho usato è MinGW32 gcc 3.4.2...

RaouL_BennetH

14-09-2005, 17:12

Infatti quello hce ho usato è MinGW32 gcc 3.4.2...

ah,scusa,avendo letto il riferimento di Cesare al gcc 4.0 pensavo avessi utilizzato quello (semprechè mi ricordi bene.....porca paletta! che periodaccio che sto attraversando..... :muro: )

P.S.: giusto per persistere con le castronerie....ma non è che MingW32 in quanto "32" non ottimizzi poi troppo bene con un processore a 64?!?

cdimauro

15-09-2005, 11:26

No, MingW utilizza il GCC, per cui alla fine le ottimizzazioni sono per forza di cose quelle... Se GCC permette di ottimizzare per l'A64, lo farà anche MingW, seppur con codice a 32 bit (per adesso MingW non supporta il codice a 64 bit).

RaouL_BennetH

15-09-2005, 13:14

No, MingW utilizza il GCC, per cui alla fine le ottimizzazioni sono per forza di cose quelle...

Uhm..guarda,saprò essere più preciso appena torno a casa,ma credo di ricordare che anche il tipo di opzioni siano cambiate con GCC 4.0 (riferendomi a -mtune e -march).Concedimi solo il beneficio del dubbio finchè non rientro a casa :)

Se GCC permette di ottimizzare per l'A64, lo farà anche MingW, seppur con codice a 32 bit (per adesso MingW non supporta il codice a 64 bit).

Ecco,quindi credo che il mio dubbio possa essere legittimo,cioè,se mingw non supporta i 64 bit,anche se gli passiamo delle opzioni per un'architettura a 64,siamo sicuri che facciano il proprio dovere?Non si potrebbe fare un esempio anche con un compilatore a 64 bit e vedere cosa cambia?!?

cionci

15-09-2005, 13:16

Ma se lo compili a 64 bit non lo puoi far girare su un sistema a 32 bit...

RaouL_BennetH

15-09-2005, 13:21

Ma se lo compili a 64 bit non lo puoi far girare su un sistema a 32 bit...

:) si, è ovvio. Mi chiedevo solo se ci potessero essere differenze significative o che giustifichino comportamenti strani come quelli da te riportati.Io purtroppo un sistema a 64 bit credo che mi ci vogliano ancora un paio di anni senza mangiare per comprarmelo :D non ho nessun modo di fare qualche prova (lol!! come se io fossi in grado di sapere che prove fare !!! uhauhauha :D )

cionci

15-09-2005, 13:28

Non ti credere che costi tanto... Con 230 € sul emrcatino ho preso Athon 64 3000+ + dissy, A8N-SLI e ATI X300...e rivendendo il mio vecchio praticamente ci ho messo solo 90€ ;)

cdimauro

15-09-2005, 14:39

Uhm..guarda,saprò essere più preciso appena torno a casa,ma credo di ricordare che anche il tipo di opzioni siano cambiate con GCC 4.0 (riferendomi a -mtune e -march).Concedimi solo il beneficio del dubbio finchè non rientro a casa :)
E' possibilissimo.
Ecco,quindi credo che il mio dubbio possa essere legittimo,cioè,se mingw non supporta i 64 bit,anche se gli passiamo delle opzioni per un'architettura a 64,siamo sicuri che facciano il proprio dovere?Non si potrebbe fare un esempio anche con un compilatore a 64 bit e vedere cosa cambia?!?
Non cambia quasi nulla, IMHO, perché MingW usa comunque tutti gli strumenti GNU che sei abituato a usare con Linux, fra cui appunto GCC, G++, ecc.

Potrebbe anche riuscire a compilare un'applicazione generando codice per x86-64, ma dubito che giri sotto Windows x64. Ti spiego anche il perché.

Il motivo per cui con MingW è possibile compilare sorgenti per sistemi Unix-like, è che questo ambiente mette a disposizione uno stub per gli eseguibili Win32, che cerca di "emulare" in qualche modo le API disponibili in un ambiente POSIX-compliant.

Stub che, IMHO, non hanno ancora realizzato per la piattaforma Windows x64, per cui non dovrebbe essere possibile generare applicazioni a 64 bit a tutti gli effetti e lanciarle.

cionci

15-09-2005, 15:32

Il motivo per cui con MingW è possibile compilare sorgenti per sistemi Unix-like, è che questo ambiente mette a disposizione uno stub per gli eseguibili Win32, che cerca di "emulare" in qualche modo le API disponibili in un ambiente POSIX-compliant.

MinGW si linka dinamicamente a msvcrt.dll... Quello con lo stub è Cygwin con cygwin.dll...
MinGW infatti nonstante che fornisca molte system call di Unix ed alcune funzioni delle librerie di Unix (getopt ad esempio), queste sono wrappate direttamente su chiamate a msvcrt.dll...
Inoltre i pacchetti per la compilazione forniti e l'ambiete MSYS sono compatibili con quelli GNU per poter usare lo stesso sistema di compilazione e gestione delle configurazione e makefile...

cdimauro

15-09-2005, 15:59

cionci

15-09-2005, 16:11

Sì, ma il codice che effettua il wrapping di msvcrt.dll in che forma è disponibile? Se è disponibile soltanto in versione a 32 bit, l'applicazione sarà incapace di girare su Windows x64, se non in un ambiente a 32 bit tramite WOW64.

Per "stub" mi riferivo al codice che funge da "interfaccia" col s.o.: poco importa se poi fa ricorso a msvcrt.dll o utilizzi un'altra libreria (cygwin.dll).
msvcrt.dll è la dll dei programmi fatti con Visual C++ in pratica esporta tutte le funzioni della libreria standard... In pratica è il wrapping con le API della libreria standard... cygwin.dll è un wrapping della libreria standard GNU che poi va a richiamare msvcrt.dll...

Quello che volevo dire è che con Cygwin c'è un layer in più e meno complesso...perchè MinGW32 non fornisce TUTTA la glibc...ma solo alcune funzioni che rendono semplice il porting (come la getopt)...
Di fatto scrivi un programma in C/C++ per console su Visual C++ e poi lo passi a MinGW32 e compila al 100%...
Portare MinGW32 ai 64 bit non sarà un lavoro complicato...

cdimauro

15-09-2005, 16:29

Sì, avevo capito. Infatti volevo soltanto dire che quel che manca adesso è soltanto il porting del codice per generare eseguibili perfettamente in grado di girare in LongMode.

Anche secondo me non ci vorrà molto: manca la volontà di farlo al team di MingW. Infatti hanno detto che al momento non è previsto perché la piattaforma Windows x64 non è molto diffusa.

Speriamo che facciano presto, perché mi piacerebbe vedere girare il MAME in versione "nativa" su Windows x64... ;)

BountyKiller

16-09-2005, 15:42

Non credo che lo stadard imponga quelle dimensioni...

le indicazioni di ANSI si riferiscono al minimo numero di bit per ciascun tipo.... quanti ne vengono usati dipende dall'architetura della cpu, dal compilatore e penso anche (talvolta) dal sistema operativo...... il fatto che non esista una specifica uguale sempre e comunque è una cosa che mi ha sempre infastidito :fagiano:

cdimauro

19-09-2005, 11:32

Che io ricordi, lo standard non parla mai di dimensione minima, nemmeno in bit, dei tipi che dovrebbe avere.

Se non sbaglio dice soltanto che sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long).

BountyKiller

19-09-2005, 11:55

:ave: Herbert Schildt - " Il linguaggio C, guida completa" - McGrawHill , pagina 17

BountyKiller

19-09-2005, 16:07

provate a compilare questo:
#include <iostream.h>

void main(void)
{
cout<<"char: "<<sizeof(char)*8<<" bit"<<endl;
cout<<"short: "<<sizeof(short)*8<<" bit"<<endl;
cout<<"int: "<<sizeof(int)*8<<" bit"<<endl;
cout<<"long: "<<sizeof(long)*8<<" bit"<<endl;
cout<<"float: "<<sizeof(float)*8<<" bit"<<endl;
cout<<"double: "<<sizeof(double)*8<<" bit"<<endl;
cout<<"long double:"<<sizeof(long double)*8<<" bit"<<endl;
return;
}

interessante notare come ci sia differenza già tra il visual C++ 6.0 e Dev-C++.....

cionci

19-09-2005, 18:57

In VC++ per abilitare i long double a 80 bit (che poi vengono allineati a 96) biosogna dare un'opzione al compilatore...

cdimauro

20-09-2005, 10:04

x BountyKiller: hai dimenticato di inserire il long long... :p

wisher

20-09-2005, 13:47

http://www.hwupgrade.it/forum/newreply.php?do=newreply&noquote=1&p=9500113

se vi può essere utile, io con un pentium M 740 1,7Ghz ho fatto:

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

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

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

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

utilizzando come compilatore DevC++ con impostazione Compilazione ottimizzata migliore e ottimizzazioni minori attivate, questo è il log della compilazione:

Esecuzione di g++.exe...
g++.exe "C:\Documents and Settings\Utente\Desktop\matrixUpDown.cpp" -o "C:\Documents and Settings\Utente\Desktop\matrixUpDown.exe" -fexpensive-optimizations -O3 -I"C:\Dev-Cpp\lib\gcc\mingw32\3.4.2\include" -I"C:\Dev-Cpp\include\c++\3.4.2\backward" -I"C:\Dev-Cpp\include\c++\3.4.2\mingw32" -I"C:\Dev-Cpp\include\c++\3.4.2" -I"C:\Dev-Cpp\include" -L"C:\Dev-Cpp\lib"
Esecuzione terminata
Compilazione terminata correttamente

p.s.
come attivo la compilazione ottimizzata per i pentium M?

andreaM

20-09-2005, 16:37

http://www.hwupgrade.it/forum/newreply.php?do=newreply&noquote=1&p=9500113

se vi può essere utile, io con un pentium M 740 1,7Ghz ho fatto:

Grazie wisher.

C'è qualche anima buona che lo può compilare su un Pentium 4? Qui da me solo AMD...