[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[Pkg-octave-devel] LEG: Optimisation and porting - assembly

Hi,

you might have read about the initiative from Linaro to detect assembly
code in Free Software to increase portablility.  I checked their list
for packages inside Debian Med (which became fairly easy by using the
recent not yet published stuff to solve #703402) and here is the list of
packages with some relevance for Debian Med that might deserve some
checking whether it might be possible to dissable / remove assembly
code.  I also add relevant contact (upstream or Debian maintainer in
case of generic packages like octave) in CC.

  abyss       <sjackman@bcgsc.ca>
  bowtie      <blangmea@jhsph.edu>
  emboss      <emboss-bug@emboss.open-bio.org>
  genometools <steinbiss@zbh.uni-hamburg.de>
  ginkgocadx  <carlos.barrales@metaemotion.com>
  gmap        <twu@gene.com>
  gromacs     <nbreen@ofb.net>
  jellyfish   <gmarcais@umd.edu>
  maude       <eker@csl.sri.com>
  mothur      <pschloss@umich.edu>
  octave      <pkg-octave-devel@lists.alioth.debian.org>
  paraview    <mathieu.malaterre@gmail.com>
  praat       <rafael@laboissiere.net>
  r-base      <edd@debian.org>
  ugene       <ugene@unipro.ru>

For more information about the ASM issue I attached an extract from the
result of the study concerning the packages listed above.  It would be
nice if you could check the possibility to remove / replace / deactivate
assembly code to make the software easily portable (for instance to cool
architectures like ARM64).

BTW, I also think that

  fis-gtm     <luis.ibanez@kitware.com>, <Amul.Shah@fisglobal.com>

(which is not yet released as Debian package and thus not part of the
study) is affected.

Kind regards

      Andreas.

[1] https://wiki.linaro.org/LEG/Engineering/OPTIM/Assembly
-- 
http://fam-tille.de
Title: Tables

debian-med.tsv
-1 == ignore, S = Source files A = Atomics
not relevant E = Embedded E = Embedded library code
F = False +ve F = False +ve
L = Lowlevel
O = OtherOS
P = Performance
Ubuntu S = Symbols/sections etc.
Package name Version Priority Type Function Comments
abyss 1.3.4-2 20 E P Biology package; embedded x86 asm for popcnt; low priority for LEG
bowtie 20 E A ultrafast, memory-efficient short read aligner (science apps); x86 asm for atomics, no threading in the code otherwise; needs porting, but not a priority
emboss 6.4.0-4 0 F F Biology package; scanner confused by test data files with .s suffix
genometools 1.4.2-4 0 E P genome analysis toolkit; x86 asm in embedded libs (zlib, sqlite); no direct porting needed
ginkgocadx 2.12.0.4889-1ubuntu1 0 E L Medical Imaging Software; asm in embedded copy of sqlite; no direct porting needed
gmap 2012-06-12-1ubuntu1 20 E P Biology software; x86 asm for bitwise ops; not a priority
gromacs 4.5.5-2 10 SE P Scientific modelling package; asm for performance for some arches, but not A32/A64
jellyfish 1.1.5-1 −1 E P genetics analysis; only supported on x86-64 because of internal fast maths routines; IGNORE
maude 2. 6. 02 20 E P framework/language for logic specification and programming; optional x86 asm for performance in embedded copy of dlmalloc; low priority
mothur 1.24.1-1 0 F F scientific sequence analysis suite; x86 asm for timer access, actually unused
octave 3.6.2-5 0 E E Embedded copy of gnulib; no direct porting needed
paraview 3.14.1-7 0 SE E Scientific visualisation tool; asm for performance in embedded libs (libpng, freetype, theora, sqlite, vtk); no direct porting needed AFAICS
praat 5.3.16-1 0 E E speech analysis and synthesis; asm in embedded codecs/libs (mad/mp3, flac, gsl, portaudio); no direct porting needed
r-base 2.15.2-1ubuntu1 0 SE EO GNU R statistical computation; asm in embedded libs (zlib/pcre/xz/valgrind/xdr/gettext), Windows support; no direct porting needed
ugene 1.9.8+repack-0ubuntu4 20 E ALOP integrated bioinformatics toolkit; optional x86 asm for CPUID, optional x86 asm for atomics with fallback to pthreads, (disabled) x86 asm for maths performance, Windows asm for debugging and timer access; would perform better with porting, but not a priority
Reply to: