On Saturday 24 July 2010 14:01:59 Joakim Tjernlund wrote: > Joakim Tjernlund <joakim.tjernl...@transmode.se> wrote on 2010/07/20 20:02:53: > > From: Joakim Tjernlund <joakim.tjernl...@transmode.se> > > To: bacula-devel@lists.sourceforge.net > > Cc: Joakim Tjernlund <joakim.tjernl...@transmode.se> > > Date: 2010/07/20 20:24 > > Subject: [Bacula-devel] [PATCH 1/2] Initial crc32 optimization. > > > > This is a strait port of the Linux kernel crc32 optimization > > I did a while ago. This impl. is several times faster than the one it > > replaces. Adapted to bacula usage. > > --- > > > > I have not tested this yet as I went/is on vacation but I figured > > perhaps someone else is interrested enough to do that :) > > > > bacula/src/lib/crc32.c | 386 > > ++++++++++++++++++++++++++++++++++++++++-------- 1 files changed, 325 > > insertions(+), 61 deletions(-) > > So it has been a few days and I was hoping for one or two comments by now.
I have been terribly busy with *big* problems and past due deadlines. > One thing I have noticed is that Bacula seems to rely on dynamic > endian detection instead of detecting endian at configure/compile time. Yes. > Is this so and does it need to stay this way? I am not sure. A Mac developer was trying to create a single binary that would run on multiple architectures, which is a good idea if it will work. I don't know whether he actually uses it or not. > > Currently the new crc32 code needs compile time detection of endianess > and I like to keep it that way. Furthermore I suspect I won't be able to > do much more Bacula work as vacation ends in one week and work at > my dayjob is piling up. The first thing to do is to fill out an FLA and send it in. See www.bacula.org -> FLA License Then the next step is to ensure that your new code and the old code can be run in unit test and can read files for CRC from STDIN. Then we can compare the results of the old code with the new code and the speed. Based on those results we can see if we need to dynamically detect which algorithm to use, and if yours is not identical, and is faster, then we would need to modify the Volume format to account for this and do the dynamic detection based on the volume format. All future versions of Bacula *must* be able to correctly read older Volume versions. Best regards, Kern > > Jocke > > > --------------------------------------------------------------------------- >--- This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > Bacula-devel mailing list > Bacula-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-devel ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
