Re: kmc update and options to move forward
Hi Étienne,
On Tue, Dec 08, 2020 at 10:49:21PM +0100, Étienne Mollier wrote:
> I recently uploaded kmc 2.3+dfsg-10 to address #954270. I'm not
> very satisfied with my patch however, as it is a mere cap of the
> default threading value, while waiting for a cleaner fix, which
> exists and it is kind of frustrating. :(
Thanks for your continuous work on this package which is very welcome.
>
> [1] https://github.com/refresh-bio/KMC/releases
> [2] https://github.com/refresh-bio/KMC/issues/82
>
> The current kmc 2.3 benefits from wide architecture support, but
> kmc 3.1.1 comes with highly optimized use of intrinsics, and CPU
> extensions runtime detection. This makes it very fast on recent
> x86_64, but unsuitable on any other architecture, as is.
Given that our main target architecture is x86_64 and moreover that we
should probably always gain for latest upstream versions if there is no
good reason to stick to something older I think we should concentrate
on kmc 3.x.
> I thought about integrating SIMDe, but for the moment, I failed
> at it. I'm not entirely certain SIMDe will deal well with the
> existing runtime detection within the code either. Also, I'm
> not very good at C++ (I learned C first unfortunately), so maybe
> I just missed my point when trying to integrate SIMDe. If
> someone else is more at ease with SIMDe integration, maybe kmc
> 3.1.1 would be up to multiple architectures support that way ?
Any SIMDe volunteer is really welcome. However, if it turns out
to be too complex I think its worth considering to upload the
unchanged upstream code first and enhance it with SIMDe later.
> Otherwise, there is a bug open about lack of Aarch64 support[3],
> but no answer for the moment. I would prefer not to resort to
> architecture removal without good reasons, but that would remain
> a last resort option I guess.
I agree that arm64 is gaining more and more importance - also given that
probably in the life time of Debian 11 Apple will switch to this
architecture. But loosing other architectures that are nearly never
used in our field is not a big deal IMHO.
Kind regards
Andreas.
> [3] https://github.com/refresh-bio/KMC/issues/154
--
http://fam-tille.de
Reply to: