Re: [asmlib] - Library of optimized subroutines coded in assembly language.
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
Reply to: