Newsgroup: it.comp.lang.c++
Titolo: OT: domanda "a basso livello"

Scusate l'OT...
avrei qualche dubbio su una cosetta a basso livello:
Tra allineamento a word, doppia word e quad word qual'e`
il piu` efficiente (in termini di velocita`) su processori
della serie pentium pro e pentium II o III?
Grazie,
Paolo
-- 
------------------------------------------------
  Paolo Marotta
  Computer Science, University of Pisa
 
http://www.cli.di.unipi.it/~marotta
  G: Potreste commentare l'attuale
     panorama informatico?
  I: /* l'attuale panorama informatico */
------------------------------------------------

Dovresti allienare a double word tutto cio' per non disallineare il cicle di
fetch del processore, sei desideri info più preciso scrivimi
    ciao
Paolo Marotta ha scritto nel messaggio ...


fetch del processore, sei desideri info più preciso scrivimi
E l'allineamento a quad word che vantaggi offre...
Grazie,
Paolo
------------------------------------------------------------------
  Paolo Marotta
  Computer Science, University of Pisa
  home:   
http://www.cli.di.unipi.it/~marotta
  G: Per concludere, possiamo chiedervi di commentare
     l'attuale panorama informatico?
  I: /* l'attuale panorama informatico */
------------------------------------------------------------------

 Paolo
In genere l'allineamento a quad word offre i suoi vantaggi
quando utilizzi tipi di dato a 64 bit (MMX, double, ed in
parte int64), dato che (memory manager permettendo) elimina
il rischio di avere la stessa variabile su due linee di
cache diverse (DCU Split, che costa di norma una decina di
cicli macchina per operazioni che normalmente ne
richiederebbero uno o due).
Comunque, allineare a quad word non è affatto inefficente,
dato che il compilatore allineerà tutti i tipi di dato più
piccoli al corretto indirizzo (es. byte = indifferente,
word = indirizzo pari, dword = indirizzo multiplo di quattro...)
Attenzione ad organizzare correttamente le strutture
di dati perchè più è "grande" l'allineamento, più aumentano
le possibilità di sprecare memoria.
Ad esempio:
#pragma pack(8)
struct Cattiva
{
 long a;   (offset 0)
 double b; (offset 8)
 long c;   (offset 16)
 long d;   (offset 20)
}; // Totale 24 bytes (4 byte buttati via)
struct Buona // Modificata e + piccola
{
 long a; (offset 0)
 long c; (offset 4)
 double b; (offset 8)
 long d; (offset 16)
}; // Totale 20 bytes
#pragma pack()
Se la prima struttura viene allineata a DWORD (4 byte)
sulle macchine RISC (ALPHA, ad esempio) verrà generata
un'eccezione di disallineamento quando il codice tenta
di leggere/scrivere nella variabile b.
Ovviamente, il memory manager utilizzato *deve* ritornare
un indirizzo che è multiplo dell'allineamento desiderato,
altrimenti è tutto inutile. Se il memory manager utilizzato
non funziona come "dovrebbe", è comunque possibile modificarlo
leggermente senza perdere troppo tempo.
Questo tipo di accorgimenti sull'allineamento valgono per
tutti i moderni processori. (Pentium, Pentium II, Pentium III,
ALPHA, PPC...)
Considera anche che le linee di cache sui processori Pentium
hanno dimensione pari a 32 byte, quindi per velocizzare alcune
parti del codice, potrebbe essere necessario allineare a 32 byte
l'indirizzo delle strutture (memory manager permettendo).
Per quanto riguarda il codice, sui processori Pentium, le
"label" chiamate da salti non condizionali, ed in particolar
modo le funzioni, dovrebbero essere allineate a 16 byte
(l'allineamento a dword è inutile in questo caso), poichè
il prefetch di queste CPU  "interpreta" blocchi di codice
con questa dimensione.
(Purtroppo la direttiva ALIGN dell'assembly inline di Visual
C++ sembra non funzionare)
Buona parte di tutto questo è rigorosamente OT, ma penso
che possa tornare utile a qualcuno.
HTH,
    Aldo Trianti.
PS: La documentazione Intel in materia è disponibile online:
http://developer.intel.com/design/pentiumii/manuals/242816.htm
http://developer.intel.com/design/pentiumii/manuals/245127.htm

Mille grazie... anche a chi ha avuto la pazienza di
sopportare questo OT.
