[fpc-pascal] Fast CRC functions?

Mark Morgan Lloyd markMLl.fpc-pascal at telemetry.co.uk
Mon Aug 25 11:30:59 CEST 2014


Juha Manninen wrote:

> Wow, with long input data strings it is 10 * faster!
> But, bummer, it returns a different value. :(
> Our CRCs are stored around in DBs and we need the same value.
> 
> I thought CRC algorith is a standard but apparently not.

<GUFFAW> Sorry, that was uncalled for.

I can't speak for highly-optimised algorithms or for SIMD stuff, and 
would also suggest that the appropriate implementation depends on 
whether you're checksumming an entire buffer or are doing it byte-by-byte.

There's lots of different algorithms, which may be defined by starting 
value, polynomial, and whether the value is negated at various points. 
Even assuming the same length, the CRC varies depending on the 
application: CRCs were originally designed to detect the type of 
impulsive errors you'd get on a comms line so to some extent depended on 
the bit rate relative to the predominant electrical noise which was 
typically non-random. For applications other than that, e.g. to verify a 
block of text which might be corrupted randomly, a cryptographic hash is 
better.

I've used them quite a lot over the years. A couple of years ago I was 
interfacing to a piece of test equipment and used the CRC units from 
http://www.wolfgang-ehrhardt.de/crchash_en.html to explore arbitrary 
message blocks and identify which CRC each appeared to use and (hence) 
where each one ended. I believe they can be classes as freeware, and I 
think they could usefully be added to FPC.

Another useful resource for those with plenty of time on their hands is 
http://www.quadibloc.com

-- 
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]



More information about the fpc-pascal mailing list