2012-03-01 20 views
6

Ho verificato diverse implementazioni di CRC64. Ad esempio, this, this e this. Il problema con tutti questi è che funzionano con i byte. Tuttavia, su un sistema a 64 bit, mi piacerebbe lavorare con long (8 byte). In questo modo, avrò bisogno di iterare di meno. Ad esempio, per i dati di 128 byte, utilizzando un byte, ho bisogno di iterare 128 volte, mentre con long, avrei bisogno di ripetere solo 16 volte.checksum CRC utilizzando long (64 bit)

Esiste un'implementazione CRC64 che utilizza long o una dimensione di parola superiore a un byte? Questi schemi possono essere modificati per farlo?

+2

Se SSE è disponibile, è probabile che GCC srotoli il loop e utilizzi anche i registri XMM a 128 bit, se possibile. Quindi, prima di passare un sacco di tempo ad ottimizzare ciecamente il codice, controlla cosa sta facendo il tuo compilatore. –

+1

Ya, ma il calcolo è ciclico, che non penso possa essere vettorializzato. – pythonic

+1

Prima di provare a superare in astuzia il compilatore, controlla quanto è intelligente. GCC esegue molte analisi del ciclo, alcune delle quali sono sicuro che non hai mai sentito parlare. Può (e in effetti fa, in determinate circostanze) srotolare un ciclo anche per il calcolo ciclico. Non sto dicendo che lo fa nel tuo caso, ma devi controllare prima di procedere con le tue ottimizzazioni. –

risposta

13

Il calcolo CRC utilizza un trucco per evitare di elaborare i dati bit per bit: utilizza una tabella di ricerca che consente di elaborare più bit contemporaneamente.

L'elaborazione di n bit richiede una tabella di ricerca di dimensioni 2^n. Le implementazioni che hai collegato leggono 1 byte (8 bit) alla volta, e infatti usano tutte una tabella di ricerca di dimensioni 256 == 2^8.

L'elaborazione di 64 bit alla volta richiederebbe una tabella di ricerca di dimensioni 2^64, il che non è pratico. Questo è il motivo per cui le implementazioni comuni di CRC eseguono l'elaborazione di 1 byte alla volta.

Mentre è possibile elaborare 2 byte alla volta utilizzando un array 65536-entry, è probabile che abbia un impatto negativo sulle prestazioni a causa dell'utilizzo di più memoria cache della CPU.

+1

BTW, sai se le tabelle di ricerca vengono utilizzate anche nelle implementazioni hardware? –

+0

@Vlad Non ne so molto delle implementazioni hardware. – interjay

+0

@VladLazarenko: esistono implementazioni hardware collegate a comunicazioni seriali che funzionano alla stessa velocità del baud rate, elaborando ogni bit a turno e quindi non hanno bisogno di tabelle di ricerca. – quamrana