devkev / binmat Goto Github PK

libbinmat.c is still full of old devel/debug code (mostly commented). Go through and clean/tidy it up.

It generates different output to binmat_print_matrix_slow(), so it must be wrong.

binmat-test is nice, but it's not exactly a test suite. A test suite could be a simple shell script around multiple invocations of binmat-test, exercising several different matrix sizes and powers, or it could be something more sophisticated (eg. something alongside binmat-test, written in C for portability).

Currently BINMAT_PRINTF_MODIFIER isn't set at all if binmat is built with BINMAT_DATA_TYPE set. The easiest solution is to force people to also set BINMAT_PRINTF_MODIFIER if they set BINMAT_DATA_TYPE, even if it is set to nothing or an empty string.

As noted in the source:

// Depending on the size of the matrices involved, and the depth of  
// pipelining on the arch we're running on (since conditional branching  
// destroys pipelining gains), it may be faster to just XOR the entire  
// matrices (with final masks) together, ORing against a "running result"  
// as we go.  The NOT of the running result is then the final result.  So  
// this way no conditionals or comparisons are required, and it amounts to  
// just streaming through memory doing fast bitwise operations.  

So, implement this (since it shouldn't be hard) and then run some benchmarks to see if it's worth keeping, and when.

It outputs lines of varying lengths, which can't be right.

The consts one and zero are very generic names, and risk causing namespace clashes with other software. Probably they should be renamed to binmat_one and binmat_zero respectively.