Quali sono le differenze di prestazioni tra numeri interi senza segno e con segno? [chiuso]

Sono consapevole del successo delle prestazioni quando si mescolano ints firmati con float.

È peggio mescolare ints non firmati con float?

C'è qualche hit nel mixare firmato / non firmato senza float?

Le diverse dimensioni (u32, u16, u8, i32, i16, i8) influiscono sulle prestazioni? Su quali piattaforme?

La grande penalità nel mescolare ints (di qualsiasi tipo) e float è perché questi sono in set di registri diversi. Per passare da un registro impostato all'altro, è necessario scrivere il valore in memoria e rileggerlo, il che comporta uno stallo load-hit-store .

Passare tra dimensioni diverse o firmare ints mantiene tutto nello stesso set di registri, in modo da evitare la grande penalità. Potrebbero esserci penalità minori a causa delle estensioni dei segni, ecc., Ma sono molto più piccole di un negozio con hit da carico.

Sospetto che le informazioni su Xbox 360 e PS3 in particolare saranno nascoste dietro muri solo per sviluppatori autorizzati, come la maggior parte dei dettagli di basso livello. Tuttavia, possiamo costruire un programma x86 equivalente e smontarlo per avere un'idea generale.

Innanzitutto, vediamo quali costi di ampliamento senza segno:

unsigned char x = 1;
unsigned int y = 1;
unsigned int z;
z = x;
z = y;

La parte pertinente si disassembla (utilizzando GCC 4.4.5):

    z = x;
  27:   0f b6 45 ff             movzbl -0x1(%ebp),%eax
  2b:   89 45 f4                mov    %eax,-0xc(%ebp)
    z = y;
  2e:   8b 45 f8                mov    -0x8(%ebp),%eax
  31:   89 45 f4                mov    %eax,-0xc(%ebp)

Quindi praticamente lo stesso: in un caso spostiamo un byte, nell'altro spostiamo una parola. Il prossimo:

signed char x = 1;
signed int y = 1;
signed int z;
z = x;
z = y;

Diventa:

   z = x;
  11:   0f be 45 ff             movsbl -0x1(%ebp),%eax
  15:   89 45 f4                mov    %eax,-0xc(%ebp)
    z = y;
  18:   8b 45 f8                mov    -0x8(%ebp),%eax
  1b:   89 45 f4                mov    %eax,-0xc(%ebp)

Quindi il costo dell'estensione del segno è qualunque sia il costo movsblpiuttosto che lo movzblè - livello di sub-istruzione. Questo è sostanzialmente impossibile da quantificare sui processori moderni a causa del modo in cui funzionano i processori moderni. Tutto il resto, che va dalla velocità della memoria alla memorizzazione nella cache a ciò che era in precedenza nella pipeline, dominerà il runtime.

In ~ 10 minuti mi sono voluti scrivere questi test, avrei potuto facilmente trovare un vero bug di prestazione, e non appena accendo qualsiasi livello di ottimizzazione del compilatore, il codice diventa irriconoscibile per compiti così semplici.

Questo non è Stack Overflow, quindi spero che nessuno qui affermi che la microottimizzazione non ha importanza. I giochi spesso funzionano su dati molto grandi e molto numerici, quindi un'attenta attenzione alla ramificazione, ai cast, alla pianificazione, all'allineamento della struttura e così via può apportare miglioramenti molto critici. Chiunque abbia trascorso molto tempo a ottimizzare il codice PPC probabilmente ha almeno una storia horror sui negozi di successo. Ma in questo caso, non importa davvero. La dimensione di archiviazione del tipo intero non influisce sulle prestazioni, purché sia ​​allineata e si adatti a un registro.

Le operazioni con numeri interi firmati possono essere più costose su quasi tutte le architetture. Ad esempio, la divisione per una costante è più veloce se non firmata, ad esempio:

unsigned foo(unsigned a) { return a / 1024U; }

sarà ottimizzato per:

unsigned foo(unsigned a) { return a >> 10; }

Ma...

int foo(int a) { return a / 1024; }

ottimizzerà per:

int foo(int a) {
  return (a + 1023 * (a < 0)) >> 10;
}

o su sistemi in cui la ramificazione è economica,

int foo(int a) {
  if (a >= 0) return a >> 10;
  else return (a + 1023) >> 10;
}

Lo stesso vale per il modulo. Questo vale anche per i non-poteri-di-2 (ma l'esempio è più complesso). Se la tua architettura non ha una divisione hardware (ad es. La maggior parte di ARM), anche le divisioni senza segno di non-cons sono più veloci.

In generale, dire al compilatore che non possono derivare numeri negativi aiuterà l'ottimizzazione delle espressioni, specialmente quelle usate per la terminazione del loop e altri condizionali.

Per quanto riguarda i formati di dimensioni diverse, sì, c'è un leggero impatto, ma dovresti pesarlo rispetto a spostare meno memoria. In questi giorni probabilmente guadagni di più accedendo a meno memoria di quanto perdi dall'espansione delle dimensioni. Ti interessa molto la microottimizzazione a quel punto.

Le operazioni con int con o senza segno hanno lo stesso costo sui processori attuali (x86_64, x86, powerpc, arm). Sul processore a 32 bit, u32, u16, u8 s32, s16, s8 dovrebbero essere gli stessi. Puoi avere penalità con un cattivo allineamento.

Ma convertire int in float o float in int è un'operazione costosa. Puoi facilmente trovare un'implementazione ottimizzata (SSE2, Neon ...).

Il punto più importante è probabilmente l'accesso alla memoria. Se i tuoi dati non rientrano nella cache L1 / L2, perderai più cicli che conversioni.

Jon Purdy dice sopra (non posso commentare) che unsigned potrebbe essere più lento perché non può traboccare. Non sono d'accordo, l'aritmetica senza segno è l'aritmetica moolare semplice modulo 2 per il numero di bit nella parola. Le operazioni firmate in linea di principio possono subire overflow, ma di solito sono disattivate.

A volte puoi fare cose intelligenti (ma non molto leggibili) come impacchettare due o più elementi di dati in un int e ottenere più operazioni per istruzione (pocket arithmetic). Ma devi capire cosa stai facendo. Ovviamente MMX ti consente di farlo in modo naturale. Ma a volte l'uso della più grande dimensione delle parole supportata da HW e l'imballaggio manuale dei dati ti dà l'implementazione più veloce.

Fare attenzione all'allineamento dei dati. Sulla maggior parte delle implementazioni HW carichi e negozi non allineati sono più lenti. Allineamento naturale, significa che per dire una parola di 4 byte, l'indirizzo è un multiplo di quattro e gli indirizzi di parola di otto byte devono essere multipli di otto byte. Ciò si ripercuote su SSE (128 bit favorisce l'allineamento a 16 byte). AVX estenderà presto queste dimensioni dei registri "vettoriali" a 256 bit, quindi a 512 bit. E i carichi / depositi allineati saranno più veloci di quelli non allineati. Per i fanatici di HW, un'operazione di memoria non allineata può estendersi a cose come la cacheline e persino i confini della pagina, per i quali l'HW deve stare attento.

È leggermente meglio usare numeri interi con segno per gli indici di loop, perché l'overflow con segno non è definito in C, quindi il compilatore supporrà che tali loop abbiano un numero inferiore di casi angolari. Questo è controllato da "-fstrict-overflow" di gcc (abilitato di default) e l'effetto è probabilmente difficile da notare senza leggere l'output dell'assembly.

Oltre a ciò, x86 funziona meglio se non mescoli tipi, perché può usare operandi di memoria. Se deve convertire tipi (segno o zero estensioni) ciò significa un carico esplicito e l'uso di un registro.

Attenersi a int per le variabili locali e la maggior parte di ciò avverrà per impostazione predefinita.

Come sottolinea celion, il sovraccarico della conversione tra ints e float ha in gran parte a che fare con la copia e la conversione dei valori tra i registri. L'unico sovraccarico di ints non firmati in sé e per sé deriva dal loro comportamento avvolgente garantito, che richiede una certa quantità di controllo di overflow nel codice compilato.

Non vi è praticamente alcun sovraccarico nella conversione tra numeri interi con o senza segno. Diverse dimensioni di numeri interi possono essere (infinitesimalmente) più veloci o più lente per accedere a seconda della piattaforma. In generale, la dimensione dell'intero più vicino alla dimensione della parola della piattaforma sarà l' accesso più veloce , ma la differenza di prestazioni complessive dipende da molti altri fattori, in particolare la dimensione della cache: se si utilizza uint64_tquando tutto ciò che serve è uint32_t, potrebbe sia che meno dei tuoi dati si adatteranno immediatamente alla cache e potresti incorrere in un sovraccarico di carico.

È un po 'eccessivo anche solo pensarci. Se usi tipi appropriati per i tuoi dati, le cose dovrebbero funzionare perfettamente e la quantità di energia che si può ottenere selezionando tipi basati sull'architettura è comunque trascurabile.