1 2This lists some acknowledged bugs that ought to be fixed. 3 4 * some reorganization is desired. Several aspects are considered. 5 - I should have a notion of "preferred I/O width", regarding how many 6 coefficients are stored together in a data file. This is thought as 7 being 64 for binary, and 1 for GF(p), and essentially unchangeable. 8 This should not preclude the possibility to run an e.g. 128-bit wide 9 code using SSE-2 for arithmetic. However, this does imply that such 10 code would have to read 2 files instead of one appropriately crafted 11 one. Consequences: 12 --> implies changing the vector I/O routines (down to pi_load_file* 13 routines) to accomodate the fact that we may read from 14 *several* vectors 15 --> get rid of the split program 16 --> get rid of the Y file 17 --> get rid of the global F file 18 - filename-based data shows its limits. Rather than passing ys=x..y to 19 binaries, specifying the V file to start from is in fact a pretty 20 workable solution. For example krylov would have to match against 21 ".\d+$" for detecting the iteration number, create the next file, 22 and create the A file based on the V file name. 23 - acollect should go, too. This would be eased by the "preferred I/O 24 width change", as we would then enforce a much simpler control for 25 what acollect currently does. 26 - bwc.pl recursive control loop is really crazy, this has to go. The 27 script in itself should probably be converted to something in 28 python. 29 This reorganization should leave us with only V, A, F, and S files. 30 31 * binary lingen is slow. Deserves a complete rewrite. 32 33 * Tuning for the assembly routines for the matrix multiplication has 34 never been done. Doing this properly should get a speed-up. Likewise, 35 the assembly code can certainly be improved. Perhaps auto-detect cache 36 sizes ? 37 38 39Also some done items. 40 41 [done] code in matops.c and abase-binary-dotprod-backends.h is sometimes 42 duplicated. This should be factored. 43 [abase-binary-dotprod-backends.h is dead now, and the 44 corresponding code has been factored in a layer inside mpfq which 45 automatically generates the required code] 46 [Mon Mar 21 15:54:53 2011, svn 749] 47 48 [done] prep.c supports some sort of seeding. Unfortunately, this is 49 ineffective in multithreaded context. 50 [we resort to saving a binary blob, which is uniquely determined 51 by the seed, and later on re-read it as a vector] 52 [Sun Nov 28 22:17:59 2010, svn 508] 53 54