Hi Jorge, On Thu, Nov 06, 2014 at 11:38:01AM +0000, Jorge Sebastião Soares wrote: > KMC said: > > > These libraries are provided with KMC source codes in a binary form. You > can find them here: > https://github.com/js21/kmc/tree/master/kmer_counter/libs > The ones with "lib" extension are for windows compilation (Visual Studio > compiler) and the ones with "a" extension are for linux compilation (g++ > compiler). > > Jorge said: > > I know that zlib is a available as a debian package and it will be easy > > to simply state it as a dependency for KMC.
+1 > KMC said: > > Asmlib is essential in performance sense. In KMC there is a lot of work > with buffers, sometimes these buffers or its part must be copied and asmlib > provide quicker copying than standard implementation. I'd keep on asking two things: 1. How quick means "quicker". What factor of speed does the usage of asmlib gain? 2. Is there any chance to provide a compile time option --without-amslib or whatever name which simply uses the native implementation? > > In the sense what I wrote above I personally would be happy if KMC > > authors would use plain C/C++ code and do some serious testing what > > speed they really gain and how maintainable their code would be. > > > > I will see if I can get some evidence form the KMC authors as to why they > choose this implementation, rather than native. Fine. At least an optional usage should come pretty cheap with some preprocessor statements. > I also thought this task would be much simpler than what it's turning out > to be. ... as always. ;-) > > Here we are facing another drawback of asmlib usage: KMC authors are > > excluding promising architectures like arm64 and ppc64el which might in > > the not so distant future could become relevant for tasks in > > bioinformatics. > > Very valid point. I will bring this point accross on the next communication. > I can cc you if you want. If you want to talk to them directly, that could > also help. I'd consider it the best idea to CC debian-med list. I'm definitely no expert about assembly code and we could easily ask for further help on other Debian lists if the discussion is archived online. > > Summary: I would try to discuss with KMC developers whether they would > > see any chance to make amslib optional and could provide the full > > functionality without this library. Writing assembly language is to the > > best of my knowledge something you did in the 90th of last century. > > Trying to reimplement things like memcmp, memcpy etc is something you > > should avoid IMHO. > > > > > 100% agreed. As above, approached the subject, and there were arguments for > using these reimplementations. > I'll send them an email later today. They are busy writing the next version > of KMC and have become slightly irresponsive as of late. Well, this happens. BTW, I had a *very* short sneak into the code and by doing one pretty simple experiment with kmc-2.0/kmer_counter $ diff -u mem_disk_file.cpp.orig mem_disk_file.cpp --- mem_disk_file.cpp.orig 2014-10-23 16:22:21.000000000 +0200 +++ mem_disk_file.cpp 2014-11-06 13:47:09.834995768 +0100 @@ -10,7 +10,10 @@ */ #include "mem_disk_file.h" -#include "libs/asmlib.h" + +// #include "libs/asmlib.h" +#define A_memcpy memcpy +#define nullptr NULL //---------------------------------------------------------------------------------- // Constructor The compiler revealed only issues which are probably caused by something else than asmlib. So wrapping this into #ifdef statements could help here - but please consider this as the most simple experiment to look how our chances to avoid asmlib are and not as real code. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141106125028.gj14...@an3as.eu