This DLL calculates a CRC 32-bit of a file. ASM source included.
The algorithm is fast like WIN-SFV :)
Posted on 2004-03-29 02:39:46 by Zord
It would be more useful to split your code in two: one routine that does the grunt CRC32 processing, and one that uses the grunt routine to process files. This way, you can work on memory buffers and memory-mapped files, too.

Second, it's bad to use global variables for a utility routine like this, you should use local stack-based variables instead. It would make your code thread-safe, and reduce the constant memory overhead of the DLL a bit.

Third, use larger buffersize - 4k doesn't allow for much performance. something like 256kb would be more like it.

Fourth, if you want really high-speed CRC32 processing of files, and especially for huge files, it would be smarter to use asynchronous I/O (overlapped files) - this allows the routine to process the crc32 of one block of data while waiting for the next block to arrive from disk.

Fifth, try using the board's search feature - http://www.asmcommunity.net/board/index.php?topic=4628&highlight=crc32 turned into a cute competition for finding a really fast algorithm.

Sorry if this sounded a bit harsh, that wasn't the intention - just to give you some ideas on how to improve your code :)
Posted on 2004-03-29 03:01:48 by f0dder
Thanks this help!
A few weaks ago i founded a C++ algorithm & i compiled this to ASM.
This algorithm calculates a 700MB file CRC around 20 sec.
WIN-SFV detto.
I thinked this algorithm enough fast for this.:sweat:

:o The criticals is always good to make your code better
Posted on 2004-03-29 13:44:25 by Zord
The algorithm itself isn't too bad, it's a good blend that works well across most processors - nothing wrong in using a faster algorithm though :p

The point about using local variables is important, though, and it would make sense to use larger buffers. Another idea would be using FILE_FLAG_NO_BUFFERING, so that you don't trash the filesystem cache when checksumming large files like ISOs or DivX's.

Another optimization that springs to mind is to run InitTable on DLL_PROCESS_ATTACH, instead of every CalcCRC32 call.

Thanks for posting your code, and don't be afraid to do so in the future - it's not about having the fastest code at hand, it's about learning and/or teaching (and sometimes achieving some pretty good code as a result of this).

:alright:
Posted on 2004-03-29 14:05:38 by f0dder
Hey Zord, I don't see an attached file, can you please reattach.
Posted on 2005-04-24 12:12:36 by Webring
I uploaded my currently used CRC algo, becouse i don't have that dll version & that was only just a test.
I tested this CRC algorithm with overlapped mode,thread,no buffering,etc and this version was the fastest on my computer.
If you growing the buffer, i think it's greater if you allocate the buffer at runtime (GlobalAlloc), the compile is very slow on big .data? sections.

download: http://rapidshare.de/files/1470185/Crc32.zip.html
Posted on 2005-04-28 02:38:44 by Zord

If you growing the buffer, i think it's greater if you allocate the buffer at runtime (GlobalAlloc), the compile is very slow on big .data? sections.

That's a well-known MASM defect - and rather silly :)
Posted on 2005-04-28 09:46:58 by f0dder
This DLL calculates a CRC 32-bit of a file. ASM source included.

update a little.
Attachments:
Posted on 2005-04-28 10:21:14 by dcskm4200