Mac chat


chest
 Share

Recommended Posts

  • Replies 22.6k
  • Created
  • Last Reply

Top Posters In This Topic

Quando si passa come parametro il 10000000 direi che questi 10 milioni di elementi degli array K e J stanno proprio in ram.

Nota per Andrea: questo accumulo di valori è fatto APPOSTA, se mi cancelli l'array in linea di principio il codice può stare tutto in cache di primo livello... Anche se può essere interessante misurare le differenze (ma prima finieri di esaminare il codice di Olaf).

Per Olaf: continuo a non capire le istruzioni

srand(clock());

j = (float)rand() / RAND_MAX;

me le spieghi???

Inoltre: la parte eseguita 10 milioni di volte ("N volte"), quanti byte consuma di Ram ad ogni ciclo? E come codice del processore?

Infine: la mia richiesta di valutare il tempo ad ordini di grandezza di 10 non derivava dal computo del tempo totale. I risultati trovati per N = 10 milioni non mi stupiscono poi tanto. Anzi, un bus a 32 bit ad 1Ghz dovrebbe in linea di principio far viaggiare 32Gigabit/secondo di dati, mentre anche nel caso migliore di Macteo mi pare che al massimo siamo sui 100Mbit...

Vi pare?

Link to comment
Share on other sites

Quando si passa come parametro il 10000000 direi che questi 10 milioni di elementi degli array K e J stanno proprio in ram.

Nota per Andrea: questo accumulo di valori è fatto APPOSTA, se mi cancelli l'array in linea di principio il codice può stare tutto in cache di primo livello... Anche se può essere interessante misurare le differenze (ma prima finieri di esaminare il codice di Olaf).

Per Olaf: continuo a non capire le istruzioni

srand(clock());

j = (float)rand() / RAND_MAX;

me le spieghi???

Inoltre: la parte eseguita 10 milioni di volte ("N volte"), quanti byte consuma di Ram ad ogni ciclo? E come codice del processore?

Infine: la mia richiesta di valutare il tempo ad ordini di grandezza di 10 non derivava dal computo del tempo totale. I risultati trovati per N = 10 milioni non mi stupiscono poi tanto. Anzi, un bus a 32 bit ad 1Ghz dovrebbe in linea di principio far viaggiare 32Gigabit/secondo di dati, mentre anche nel caso migliore di Macteo mi pare che al massimo siamo sui 100Mbit...

Vi pare?

Link to comment
Share on other sites

Quando si passa come parametro il 10000000 direi che questi 10 milioni di elementi degli array K e J stanno proprio in ram.

Nota per Andrea: questo accumulo di valori è fatto APPOSTA, se mi cancelli l'array in linea di principio il codice può stare tutto in cache di primo livello... Anche se può essere interessante misurare le differenze (ma prima finieri di esaminare il codice di Olaf).

Per Olaf: continuo a non capire le istruzioni

srand(clock());

j = (float)rand() / RAND_MAX;

me le spieghi???

Inoltre: la parte eseguita 10 milioni di volte ("N volte"), quanti byte consuma di Ram ad ogni ciclo? E come codice del processore?

Infine: la mia richiesta di valutare il tempo ad ordini di grandezza di 10 non derivava dal computo del tempo totale. I risultati trovati per N = 10 milioni non mi stupiscono poi tanto. Anzi, un bus a 32 bit ad 1Ghz dovrebbe in linea di principio far viaggiare 32Gigabit/secondo di dati, mentre anche nel caso migliore di Macteo mi pare che al massimo siamo sui 100Mbit...

Vi pare?

Link to comment
Share on other sites

Olaf: <FONT COLOR="ff6000">Comunque, come dice Camillo, il programma non genera un gran traffico.</FONT>

Non è proprio così.

Chest: <FONT COLOR="ff0000">E' sufficiente poter escludere che basti la cache a contenere i valori dell'array, ma che occorra per forza la cosa che mi pare sia vera. No?</FONT>

Il problema è che ci sono troppi calcoli. Chiamare una funzione, generare un numero casuale, convertirlo in virgola mobile, fare la divisione... anche il bus più farlocco fa ampiamente in tempo a completare il trasferimento mentre il processore fa tutte queste cose. In altre parole, il limite è posto dalla velocità del processore, non da quella della RAM.

Ricordate che tutti i processori moderni hanno una pipeline con la possibilità di riordinare le istruzioni, quindi, anche se uno cerca di costringere il processore ad aspettare i tempi della RAM mettendo le istruzioni del programma in un certo ordine, la CPU se può evitare di andare in stallo lo fa comunque.

Se volete provare la velocità della RAM, allocate due blocchi di memoria belli grossi e copiate da uno all'altro (in unità delle dimensioni di un registro, altrimenti servono altre operazioni). Oppure create un unico blocco ed inizializzate ogni word a 0xDEADBEEF. Meglio fare entrambi i test, così vediamo se c'è qualche differenza.

Link to comment
Share on other sites

Olaf: <FONT COLOR="ff6000">Comunque, come dice Camillo, il programma non genera un gran traffico.</FONT>

Non è proprio così.

Chest: <FONT COLOR="ff0000">E' sufficiente poter escludere che basti la cache a contenere i valori dell'array, ma che occorra per forza la cosa che mi pare sia vera. No?</FONT>

Il problema è che ci sono troppi calcoli. Chiamare una funzione, generare un numero casuale, convertirlo in virgola mobile, fare la divisione... anche il bus più farlocco fa ampiamente in tempo a completare il trasferimento mentre il processore fa tutte queste cose. In altre parole, il limite è posto dalla velocità del processore, non da quella della RAM.

Ricordate che tutti i processori moderni hanno una pipeline con la possibilità di riordinare le istruzioni, quindi, anche se uno cerca di costringere il processore ad aspettare i tempi della RAM mettendo le istruzioni del programma in un certo ordine, la CPU se può evitare di andare in stallo lo fa comunque.

Se volete provare la velocità della RAM, allocate due blocchi di memoria belli grossi e copiate da uno all'altro (in unità delle dimensioni di un registro, altrimenti servono altre operazioni). Oppure create un unico blocco ed inizializzate ogni word a 0xDEADBEEF. Meglio fare entrambi i test, così vediamo se c'è qualche differenza.

Link to comment
Share on other sites

Olaf: <FONT COLOR="ff6000">Comunque, come dice Camillo, il programma non genera un gran traffico.</FONT>

Non è proprio così.

Chest: <FONT COLOR="ff0000">E' sufficiente poter escludere che basti la cache a contenere i valori dell'array, ma che occorra per forza la cosa che mi pare sia vera. No?</FONT>

Il problema è che ci sono troppi calcoli. Chiamare una funzione, generare un numero casuale, convertirlo in virgola mobile, fare la divisione... anche il bus più farlocco fa ampiamente in tempo a completare il trasferimento mentre il processore fa tutte queste cose. In altre parole, il limite è posto dalla velocità del processore, non da quella della RAM.

Ricordate che tutti i processori moderni hanno una pipeline con la possibilità di riordinare le istruzioni, quindi, anche se uno cerca di costringere il processore ad aspettare i tempi della RAM mettendo le istruzioni del programma in un certo ordine, la CPU se può evitare di andare in stallo lo fa comunque.

Se volete provare la velocità della RAM, allocate due blocchi di memoria belli grossi e copiate da uno all'altro (in unità delle dimensioni di un registro, altrimenti servono altre operazioni). Oppure create un unico blocco ed inizializzate ogni word a 0xDEADBEEF. Meglio fare entrambi i test, così vediamo se c'è qualche differenza.

Link to comment
Share on other sites

Chest: <FONT COLOR="ff0000">Anzi, un bus a 32 bit ad 1Ghz dovrebbe in linea di principio far viaggiare 32Gigabit/secondo di dati, mentre anche nel caso migliore di Macteo mi pare che al massimo siamo sui 100Mbit...</FONT>

Il ciclo interno:

<BLOCKQUOTE>for (i = 0; i < n; i++) {

j = (float)rand() / RAND_MAX;

k[i + 1] = k + j;

}</BLOCKQUOTE>

scrive in RAM 8 byte (j e k[i+1], due float da 32 bit ciascuno) per iterazione (quando viene calcolato k[i+1], j è sempre in cache, quindi non viene mai letto dalla RAM). Con 10M iterazioni sono 640 milioni di bit. Il G5 impiega 0.78 secondi, quindi siamo intorno agli 800 Mbit/s.

Ma i dati ottenuti con questo programma, come ho spiegato, sono inferiori alle reali capacità del bus.

Link to comment
Share on other sites

Chest: <FONT COLOR="ff0000">Anzi, un bus a 32 bit ad 1Ghz dovrebbe in linea di principio far viaggiare 32Gigabit/secondo di dati, mentre anche nel caso migliore di Macteo mi pare che al massimo siamo sui 100Mbit...</FONT>

Il ciclo interno:

<BLOCKQUOTE>for (i = 0; i < n; i++) {

j = (float)rand() / RAND_MAX;

k[i + 1] = k + j;

}</BLOCKQUOTE>

scrive in RAM 8 byte (j e k[i+1], due float da 32 bit ciascuno) per iterazione (quando viene calcolato k[i+1], j è sempre in cache, quindi non viene mai letto dalla RAM). Con 10M iterazioni sono 640 milioni di bit. Il G5 impiega 0.78 secondi, quindi siamo intorno agli 800 Mbit/s.

Ma i dati ottenuti con questo programma, come ho spiegato, sono inferiori alle reali capacità del bus.

Link to comment
Share on other sites

Chest: <FONT COLOR="ff0000">Anzi, un bus a 32 bit ad 1Ghz dovrebbe in linea di principio far viaggiare 32Gigabit/secondo di dati, mentre anche nel caso migliore di Macteo mi pare che al massimo siamo sui 100Mbit...</FONT>

Il ciclo interno:

<BLOCKQUOTE>for (i = 0; i < n; i++) {

j = (float)rand() / RAND_MAX;

k[i + 1] = k + j;

}</BLOCKQUOTE>

scrive in RAM 8 byte (j e k[i+1], due float da 32 bit ciascuno) per iterazione (quando viene calcolato k[i+1], j è sempre in cache, quindi non viene mai letto dalla RAM). Con 10M iterazioni sono 640 milioni di bit. Il G5 impiega 0.78 secondi, quindi siamo intorno agli 800 Mbit/s.

Ma i dati ottenuti con questo programma, come ho spiegato, sono inferiori alle reali capacità del bus.

Link to comment
Share on other sites

olaf>nel nostro caso no, visto che poi il programma termina subito. è comunque una buona abitudine, altrimenti la memoria rimane occupata e magari in applicazioni vere può diventare un problema.

chest> ma io non ho cambiato il codice di olaf per quanto riguarda gli array. ho estratto una divisione per risparmiare cicli di cpu e ho cambiato malloc con new perché malloc è void. comunque se non vuoi utilizzare la cache di 2 livello escludila con i chud, no?

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share