Re: Project idea: port GKL to non-x86

2020-11-18 Thread Steffen Möller


On 18.11.20 10:35, Michael R. Crusoe wrote:
>
>
> On Wed, 18 Nov 2020 at 10:32, Andreas Tille  > wrote:
>
> Hi Michael,
>
> On Wed, Nov 18, 2020 at 12:00:29AM +0100, Michael Crusoe wrote:
> > With https://salsa.debian.org/java-team/gkl/-/merge_requests/3
>  I am
> able to
> > build a GKL package that runs on non-amd64 (though probably at a
> huge speed
> > sacrifice)
> >
> > Using the resulting libgkl-java package and
> >
> 
> https://salsa.debian.org/med-team/picard-tools/-/commit/a6e95fb137e4293491b84e04b780bd6ebd5cfe34
> 
> 
> > I am able to build and run Picards tools on arm64
>
> Cool.  Should I upload gkl (after some routine-update)?
>
>
> Already done :-)
>  
>
> I also wonder why that package is in java-team if only Debian Med
> members are working on it and its relevant for Debian Med.
>
>
> I don't know!

The idea typically is that if there is something happening on the Java
front with many reverse dependencies then this can be dealt with. For
some packages there should be dual-memberships.

Best,

Steffen



Re: Project idea: port GKL to non-x86

2020-11-18 Thread Michael R. Crusoe
On Wed, 18 Nov 2020 at 10:32, Andreas Tille  wrote:

> Hi Michael,
>
> On Wed, Nov 18, 2020 at 12:00:29AM +0100, Michael Crusoe wrote:
> > With https://salsa.debian.org/java-team/gkl/-/merge_requests/3 I am
> able to
> > build a GKL package that runs on non-amd64 (though probably at a huge
> speed
> > sacrifice)
> >
> > Using the resulting libgkl-java package and
> >
> https://salsa.debian.org/med-team/picard-tools/-/commit/a6e95fb137e4293491b84e04b780bd6ebd5cfe34
> > I am able to build and run Picards tools on arm64
>
> Cool.  Should I upload gkl (after some routine-update)?
>

Already done :-)


> I also wonder why that package is in java-team if only Debian Med
> members are working on it and its relevant for Debian Med.
>

I don't know!


-- 
Michael R. Crusoe


Re: Project idea: port GKL to non-x86

2020-11-18 Thread Andreas Tille
Hi Michael,

On Wed, Nov 18, 2020 at 12:00:29AM +0100, Michael Crusoe wrote:
> With https://salsa.debian.org/java-team/gkl/-/merge_requests/3 I am able to
> build a GKL package that runs on non-amd64 (though probably at a huge speed
> sacrifice)
> 
> Using the resulting libgkl-java package and
> https://salsa.debian.org/med-team/picard-tools/-/commit/a6e95fb137e4293491b84e04b780bd6ebd5cfe34
> I am able to build and run Picards tools on arm64

Cool.  Should I upload gkl (after some routine-update)?
I also wonder why that package is in java-team if only Debian Med
members are working on it and its relevant for Debian Med.

Kind regards

Andreas.

-- 
http://fam-tille.de



Re: Project idea: port GKL to non-x86

2020-11-17 Thread Michael Crusoe
With https://salsa.debian.org/java-team/gkl/-/merge_requests/3 I am able to
build a GKL package that runs on non-amd64 (though probably at a huge speed
sacrifice)

Using the resulting libgkl-java package and
https://salsa.debian.org/med-team/picard-tools/-/commit/a6e95fb137e4293491b84e04b780bd6ebd5cfe34
I am able to build and run Picards tools on arm64

On Sun, 9 Feb 2020 at 15:51, Jun Aruga  wrote:

> As I heard that igv, artemis depending on picard-tools depending on
> gkl (Intel specific code), I opened a ticket for picard-tools.
>
> This ticket might be a good start to make picard run on multiple CPUs.
> https://github.com/broadinstitute/picard/issues/1467
>
> On Sat, Feb 8, 2020 at 4:39 PM Michael Crusoe 
> wrote:
> >
> > Oh, I was mistaken about the GATK link.
> >
> > picard-tools depends on gkl, and igv and artemis depend on picard-tools
> >
> > On Sat, Feb 8, 2020 at 4:22 PM Jun Aruga  wrote:
> >>
> >> This part is related to building on ARM.
> >>
> >> > @GraceZou, You will have to build from source for ARM. The repo is
> gatk-bwamem-jni. There are instructions in the README on the repo landing
> page. Set the environmental variable to then point to the built library.
> >>
> >> On Sat, Feb 8, 2020 at 4:19 PM Jun Aruga  wrote:
> >> >
> >> > For GATK depending on GKL, I found an interesting page about building
> >> > GATK on ARM.
> >> >
> >> >
> https://gatkforums.broadinstitute.org/gatk/discussion/9971/gatk4-beta1-problem-some-questions-about-bwa-faga-pipeline-in-gatk4-beta1
> >> > > We use GATK4-beta1 in ARM,and have several questions about it:
> >> >
> >> > Jun
> >> >
> >> > On Sat, Feb 8, 2020 at 2:53 PM Michael Crusoe <
> michael.cru...@gmail.com> wrote:
> >> > >
> >> > > https://github.com/Intel-HLS/GKL
> >> > > A Java wrapper around an Intel optimized implementations of
> PairHMM, Smith-Waterman, and DEFLATE.
> >> > >
> >> > > Uses SIMD intrinsics and assembly.
> >> > >
> >> > > At
> https://salsa.debian.org/misterc-guest/gkl/tree/experimental/simde is a
> fork using the SIMD Everywhere library, but I lack the expertise to produce
> source versions of the many assembler only routines.
> >> > >
> >> > > Any suggestions / contributions?
> >> > >
> >> > > --
> >> > > Michael R. Crusoe
> >> >
> >> >
> >> >
> >> > --
> >> > Jun | He - His - Him
> >> > jar...@redhat.com / IRC: jaruga
> >>
> >>
> >>
> >> --
> >> Jun | He - His - Him
> >> jar...@redhat.com / IRC: jaruga
> >>
> >
> >
> > --
> > Michael R. Crusoe
>
>
>
> --
> Jun | He - His - Him
> jar...@redhat.com / IRC: jaruga
>
>

-- 
Michael R. Crusoe
Co-founder & Lead,
Common Workflow Language project 
https://orcid.org/-0002-2961-9670
m...@commonwl.org


Re: Project idea: port GKL to non-x86

2020-02-13 Thread Jun Aruga
Hi everyone,

Thanks for the great event!
I updated my part in the wiki - personal reports.
https://wiki.debian.org/Sprints/2020/Debian%20Med%20Sprint%20Feb%202020%2C%20Berlin

Could you share the photo we took in Vegetarian restaurant somewhere?
And this is the photo shared on twitter for someone who does not know it.
https://twitter.com/biocrusoe/status/1226518240022671365

Jun

-- 
Jun | He - His - Him
jar...@redhat.com / IRC: jaruga



Re: Project idea: port GKL to non-x86

2020-02-09 Thread Jun Aruga
As I heard that igv, artemis depending on picard-tools depending on
gkl (Intel specific code), I opened a ticket for picard-tools.

This ticket might be a good start to make picard run on multiple CPUs.
https://github.com/broadinstitute/picard/issues/1467

On Sat, Feb 8, 2020 at 4:39 PM Michael Crusoe  wrote:
>
> Oh, I was mistaken about the GATK link.
>
> picard-tools depends on gkl, and igv and artemis depend on picard-tools
>
> On Sat, Feb 8, 2020 at 4:22 PM Jun Aruga  wrote:
>>
>> This part is related to building on ARM.
>>
>> > @GraceZou, You will have to build from source for ARM. The repo is 
>> > gatk-bwamem-jni. There are instructions in the README on the repo landing 
>> > page. Set the environmental variable to then point to the built library.
>>
>> On Sat, Feb 8, 2020 at 4:19 PM Jun Aruga  wrote:
>> >
>> > For GATK depending on GKL, I found an interesting page about building
>> > GATK on ARM.
>> >
>> > https://gatkforums.broadinstitute.org/gatk/discussion/9971/gatk4-beta1-problem-some-questions-about-bwa-faga-pipeline-in-gatk4-beta1
>> > > We use GATK4-beta1 in ARM,and have several questions about it:
>> >
>> > Jun
>> >
>> > On Sat, Feb 8, 2020 at 2:53 PM Michael Crusoe  
>> > wrote:
>> > >
>> > > https://github.com/Intel-HLS/GKL
>> > > A Java wrapper around an Intel optimized implementations of PairHMM, 
>> > > Smith-Waterman, and DEFLATE.
>> > >
>> > > Uses SIMD intrinsics and assembly.
>> > >
>> > > At https://salsa.debian.org/misterc-guest/gkl/tree/experimental/simde is 
>> > > a fork using the SIMD Everywhere library, but I lack the expertise to 
>> > > produce source versions of the many assembler only routines.
>> > >
>> > > Any suggestions / contributions?
>> > >
>> > > --
>> > > Michael R. Crusoe
>> >
>> >
>> >
>> > --
>> > Jun | He - His - Him
>> > jar...@redhat.com / IRC: jaruga
>>
>>
>>
>> --
>> Jun | He - His - Him
>> jar...@redhat.com / IRC: jaruga
>>
>
>
> --
> Michael R. Crusoe



-- 
Jun | He - His - Him
jar...@redhat.com / IRC: jaruga



Re: Project idea: port GKL to non-x86

2020-02-08 Thread Jun Aruga
For GATK depending on GKL, I found an interesting page about building
GATK on ARM.

https://gatkforums.broadinstitute.org/gatk/discussion/9971/gatk4-beta1-problem-some-questions-about-bwa-faga-pipeline-in-gatk4-beta1
> We use GATK4-beta1 in ARM,and have several questions about it:

Jun

On Sat, Feb 8, 2020 at 2:53 PM Michael Crusoe  wrote:
>
> https://github.com/Intel-HLS/GKL
> A Java wrapper around an Intel optimized implementations of PairHMM, 
> Smith-Waterman, and DEFLATE.
>
> Uses SIMD intrinsics and assembly.
>
> At https://salsa.debian.org/misterc-guest/gkl/tree/experimental/simde is a 
> fork using the SIMD Everywhere library, but I lack the expertise to produce 
> source versions of the many assembler only routines.
>
> Any suggestions / contributions?
>
> --
> Michael R. Crusoe



-- 
Jun | He - His - Him
jar...@redhat.com / IRC: jaruga



Re: Project idea: port GKL to non-x86

2020-02-08 Thread Jun Aruga
This part is related to building on ARM.

> @GraceZou, You will have to build from source for ARM. The repo is 
> gatk-bwamem-jni. There are instructions in the README on the repo landing 
> page. Set the environmental variable to then point to the built library.

On Sat, Feb 8, 2020 at 4:19 PM Jun Aruga  wrote:
>
> For GATK depending on GKL, I found an interesting page about building
> GATK on ARM.
>
> https://gatkforums.broadinstitute.org/gatk/discussion/9971/gatk4-beta1-problem-some-questions-about-bwa-faga-pipeline-in-gatk4-beta1
> > We use GATK4-beta1 in ARM,and have several questions about it:
>
> Jun
>
> On Sat, Feb 8, 2020 at 2:53 PM Michael Crusoe  
> wrote:
> >
> > https://github.com/Intel-HLS/GKL
> > A Java wrapper around an Intel optimized implementations of PairHMM, 
> > Smith-Waterman, and DEFLATE.
> >
> > Uses SIMD intrinsics and assembly.
> >
> > At https://salsa.debian.org/misterc-guest/gkl/tree/experimental/simde is a 
> > fork using the SIMD Everywhere library, but I lack the expertise to produce 
> > source versions of the many assembler only routines.
> >
> > Any suggestions / contributions?
> >
> > --
> > Michael R. Crusoe
>
>
>
> --
> Jun | He - His - Him
> jar...@redhat.com / IRC: jaruga



-- 
Jun | He - His - Him
jar...@redhat.com / IRC: jaruga



Re: Project idea: port GKL to non-x86

2020-02-08 Thread Michael Crusoe
Oh, I was mistaken about the GATK link.

picard-tools depends on gkl, and igv and artemis depend on picard-tools

On Sat, Feb 8, 2020 at 4:22 PM Jun Aruga  wrote:

> This part is related to building on ARM.
>
> > @GraceZou, You will have to build from source for ARM. The repo is
> gatk-bwamem-jni. There are instructions in the README on the repo landing
> page. Set the environmental variable to then point to the built library.
>
> On Sat, Feb 8, 2020 at 4:19 PM Jun Aruga  wrote:
> >
> > For GATK depending on GKL, I found an interesting page about building
> > GATK on ARM.
> >
> >
> https://gatkforums.broadinstitute.org/gatk/discussion/9971/gatk4-beta1-problem-some-questions-about-bwa-faga-pipeline-in-gatk4-beta1
> > > We use GATK4-beta1 in ARM,and have several questions about it:
> >
> > Jun
> >
> > On Sat, Feb 8, 2020 at 2:53 PM Michael Crusoe 
> wrote:
> > >
> > > https://github.com/Intel-HLS/GKL
> > > A Java wrapper around an Intel optimized implementations of PairHMM,
> Smith-Waterman, and DEFLATE.
> > >
> > > Uses SIMD intrinsics and assembly.
> > >
> > > At https://salsa.debian.org/misterc-guest/gkl/tree/experimental/simde
> is a fork using the SIMD Everywhere library, but I lack the expertise to
> produce source versions of the many assembler only routines.
> > >
> > > Any suggestions / contributions?
> > >
> > > --
> > > Michael R. Crusoe
> >
> >
> >
> > --
> > Jun | He - His - Him
> > jar...@redhat.com / IRC: jaruga
>
>
>
> --
> Jun | He - His - Him
> jar...@redhat.com / IRC: jaruga
>
>

-- 
Michael R. Crusoe


Project idea: port GKL to non-x86

2020-02-08 Thread Michael Crusoe
https://github.com/Intel-HLS/GKL
A Java wrapper around an Intel optimized implementations of PairHMM,
Smith-Waterman, and DEFLATE.

Uses SIMD intrinsics and assembly.

At https://salsa.debian.org/misterc-guest/gkl/tree/experimental/simde is a
fork using the SIMD Everywhere library, but I lack the expertise to produce
source versions of the many assembler only routines.

Any suggestions / contributions?

-- 
Michael R. Crusoe